CloudThinker Tutorial 2025: How to Set Up Credentials for AWS

Connect AWS to CloudThinker in minutes

Most cloud tools ask for AWS access on their first screen, and most teams answer the fastest way they can: an access key from whatever user is handy, often one with far more permission than the tool needs. That key then lives on for years, outlasts the engineer who created it, and quietly becomes the broadest credential in the account.

This tutorial sets it up the other way. You'll create a dedicated IAM user that can read and never write, give it only the permissions CloudThinker needs, connect it, and confirm it works. It takes a few minutes, and the credential you end up with is one your security team can read in a single policy.

What you'll learn

Create an IAM user with least-privilege permissions
Generate an AWS Access Key ID and Secret Access Key
Configure your CloudThinker workspace with the AWS credentials
Verify the connection and confirm it's secure
Follow security best practices for credential management

01IAM

Create user

A dedicated user with no console access.

02Policy

Read only

ReadOnlyAccess, or a custom policy scoped to the services you choose.

03Keys

Access key

One key pair, created for a third-party service.

04CloudThinker

Connect

Paste the keys, pick regions, verify and connect.

05First scan

Verify

Inventory, cost data and metrics appear within minutes.

The whole setup takes a few minutes and grants nothing that can change a resource.

Watch the tutorial

Why the quick way goes wrong

Handing a tool an admin key isn't a one-time risk. It goes wrong in predictable ways:

Scope never shrinks. A key created "just to try it" keeps every permission it started with. Nobody goes back to trim it once the tool works.
Ownership blurs. A key tied to a person's IAM user breaks when that person leaves, or worse, keeps working after their access should have ended.
Blast radius is the whole account. If a key with write access leaks, the attacker gets write access. A read-only key that leaks is still an incident, but it can't delete a database.
Audits get harder. When CloudThinker's API calls share a user with a human, CloudTrail can't tell you which calls were which.

A dedicated, read-only user fixes all four. It has one job, one owner (the integration), and one policy anyone can review.

01Avoid

Admin or root keys

Full write access to everything, for a job that only needs to read.

02This tutorial

Read-only IAM user

A dedicated user with ReadOnlyAccess or a scoped policy. Simple to set up and revoke.

03Production

Cross-account role

No long-lived keys at all. Access is assumed per session and revoked by editing one role.

Three ways to give a tool access to AWS, from worst to best for long-term use.

Step-by-step guide

Prefer reading? Follow the written steps below. Each console step has an AWS CLI equivalent if you'd rather script it.

Step 1: Create an IAM user in AWS

Sign in to the AWS Management Console
Navigate to IAM (Identity and Access Management)
Select Users from the left sidebar, then click Create user
Enter a descriptive username (for example, cloudthinker-readonly)
Do not enable console access. CloudThinker only needs programmatic access

From the CLI, with an admin profile of your own:

aws iam create-user --user-name cloudthinker-readonly

Step 2: Assign least-privilege permissions

Attach a policy that grants CloudThinker read-only access to your infrastructure:

On the permissions page, select Attach policies directly
Search for and attach the ReadOnlyAccess managed policy
For tighter control, create a custom policy scoped to only the services you want CloudThinker to analyze (for example EC2, RDS, S3, CloudWatch and Cost Explorer)

aws iam attach-user-policy \
  --user-name cloudthinker-readonly \
  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

ReadOnlyAccess is the quickest choice, and it's broad: it can read data in some services as well as configuration (S3 object contents, for example). If that's more than you want, a custom policy limited to describe, list and metrics calls is tighter. Here's a starting point covering the services above; add services as you need them:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "CloudThinkerReadOnly",
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "rds:Describe*",
        "rds:ListTagsForResource",
        "s3:ListAllMyBuckets",
        "s3:GetBucketLocation",
        "s3:GetBucketTagging",
        "cloudwatch:GetMetricData",
        "cloudwatch:ListMetrics",
        "ce:GetCostAndUsage",
        "ce:GetCostForecast"
      ],
      "Resource": "*"
    }
  ]
}

Security tip: Always follow the principle of least privilege. Grant only the permissions CloudThinker needs, and never use admin or root credentials.

Step 3: Generate access keys

After creating the user, open the user's Security credentials tab
Under Access keys, click Create access key
Select Third-party service as the use case
Copy both the Access Key ID and the Secret Access Key. You won't be able to see the secret key again

aws iam create-access-key --user-name cloudthinker-readonly

The response contains AccessKeyId and SecretAccessKey. This is the only time AWS shows the secret.

Important: Store these credentials securely. Never share them in plain text, commit them to version control or expose them in client-side code.

Step 4: Configure CloudThinker

Log in to CloudThinker
Navigate to Settings > Cloud Connections
Click Add AWS Account
Paste your Access Key ID and Secret Access Key
Select the AWS regions you want CloudThinker to monitor
Click Verify & Connect

CloudThinker validates the credentials and confirms which services are accessible.

Step 5: Verify the connection

Once connected, CloudThinker starts discovering your AWS resources. Within a few minutes you should see:

Your resource inventory populated in the dashboard
Cost data flowing in from AWS Cost Explorer
Infrastructure metrics appearing in the monitoring views

If verification fails

There are three usual causes, and each one shows up differently. Check them in this order.

The keys are wrong or inactive. Configure a temporary CLI profile with the new keys and ask AWS who you are:

aws configure --profile ct-check
aws sts get-caller-identity --profile ct-check

If this returns the ARN of cloudthinker-readonly, the keys are fine. An InvalidClientTokenId error means the key ID was mistyped or the key is inactive.

The policy is missing. Confirm the policy is attached to the right user:

aws iam list-attached-user-policies --user-name cloudthinker-readonly

A specific service is denied. If inventory appears but cost data doesn't, try the same call CloudThinker needs:

aws ce get-cost-and-usage \
  --time-period Start=2025-01-01,End=2025-02-01 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --profile ct-check

An AccessDenied here means your custom policy is missing Cost Explorer actions. Cost Explorer also has to be enabled once per account (open it in the Billing and Cost Management console), and data can take up to 24 hours to appear after that. When you're done, remove the temporary profile from ~/.aws/credentials.

Why this setup beats the quick one

	Admin or personal key	Dedicated read-only user	Cross-account role
What it can change	Everything	Nothing	Nothing (with a read-only policy)
Long-lived secret	Yes	Yes, rotated every 90 days	No
Who owns it	Whoever created it	The integration	The integration
CloudTrail clarity	Mixed with a human's calls	Its own identity	Its own role sessions
Revoking access	Risky, may break other things	Deactivate one key	Edit one trust policy

The deeper difference is what you're trusting. With an admin key, you're trusting the tool never to misuse write access it was handed by accident. With a read-only identity, the question doesn't come up: the credential can't change anything, so connecting it is a decision about what CloudThinker may see, not what it may do.

Security best practices

Rotate credentials regularly. AWS recommends rotating access keys every 90 days. Create the new key, update CloudThinker, then deactivate and delete the old one:

aws iam list-access-keys --user-name cloudthinker-readonly
aws iam update-access-key --user-name cloudthinker-readonly \
  --access-key-id <OLD_KEY_ID> --status Inactive

Use IAM roles when possible. For production environments, consider cross-account IAM roles instead of access keys for stronger security
Enable MFA on the AWS account that owns the IAM user
Monitor key usage. Set up CloudTrail to audit the API calls made with your credentials
Never reuse credentials. Create a dedicated IAM user just for CloudThinker

Read-only now, actions later

Everything in this tutorial is read access. CloudThinker can analyze, report and propose, and nothing in your account changes. If you later want it to act on findings (resize an instance, delete an unattached volume), that takes a separate grant of write permissions, and even then CloudThinker acts within Auto Mode, so you decide what runs on its own and what waits for approval.

What's next?

With your AWS account connected, CloudThinker can now:

Analyze your infrastructure for cost optimization opportunities
Monitor your security posture and flag misconfigurations
Run Well-Architected assessments across all six pillars
Detect anomalies in spending and performance metrics

A good first question once the scan finishes:

"Find the five biggest cost savings in this AWS account and show the evidence for each. Propose only, change nothing."

And one for the security side:

"List public S3 buckets, security groups open to 0.0.0.0/0, and access keys older than 90 days in this account."

CloudThinker Tutorial 2025: How to set up credentials for AWS