Forem

David Nanjila
David Nanjila

Posted on

Step-by-Step Guide to Setting Up Terraform, AWS CLI, and Your AWS Environment

If you're just getting started with infrastructure as code, the first few hours can feel like you're assembling furniture without the instruction manual. You know the end goal — a working Terraform setup connected to AWS — but the path there involves a surprising number of small decisions that can trip you up if you're not careful.

This post walks through exactly what I did to get my environment up and running: AWS account setup, IAM configuration, AWS CLI installation, and finally connecting Terraform to AWS. Whether you're brand new to this or you've done bits of it before but never cleanly all at once, I'll share what I learned along the way — including the stuff I wish someone had told me upfront.

What We're Setting Up

Before we dive in, here's the full picture of what we're building across these three labs:

  • Lab 1: Set up your AWS account with proper IAM and billing configuration
  • Lab 2: Install and configure the AWS CLI
  • Lab 3: Install Terraform and connect it to AWS

Let's go step by step.

Lab 1: AWS Account Setup — Don't Skip the IAM and Billing Parts

If you already have an AWS account, you might be tempted to skip this section entirely. I'd actually encourage you not to — or at least skim it — because the IAM and billing setup tips here are genuinely worth your time, even if you've had an account for years.

Creating Your AWS Account

Head to aws.amazon.com and sign up. You'll need a credit card, but AWS has a generous free tier that covers most of what we'll be doing here. The signup process is straightforward, so I won't belabor it.

What does matter is what you do immediately after you log in for the first time.

Lock Down Your Root Account — Seriously

When you first create an AWS account, you log in as the root user. This account has unrestricted access to everything in your AWS environment — billing, account settings, all services, all regions. No guardrails. No limits.

You should never use the root account for day-to-day work.

The first thing to do is secure it:

  1. Enable Multi-Factor Authentication (MFA) on the root account

howing enable MFA in I AM page
click enable MFA and you can use authentication app to add your MFA authentication code

Showinf MFA enabled

  1. Create a strong password and store it somewhere safe (a password manager)
  2. Then step away from the root account and don't look back, Proceed to set up an IAM user.

Setting Up IAM — The Right Way

IAM (Identity and Access Management) is how AWS controls who can do what in your account. Instead of using root credentials, you create IAM users with specific permissions.

Here's the setup I used:

  1. Navigate to IAM in the AWS Console( search and click on I AM)

Showing aws management console

  1. Create a new IAM user (I named mine something like nanjila-terraform to keep it obvious) Click on users on the left menu and then click create user on top right.

IAM user creation page/window
Give your user an appropriate name and then check the provide user access to the aws management console box. Why? This is to allow the user to login to the console and also be able to connect to your console programmaticaly.
Leave everything as default and then click next to set the user permission

IAM user name

  1. Attach the AdministratorAccess policy — this gives full access but is still safer than root because it's auditable and can be revoked Click on te attach policy directly and search for the, in the search bar, type admin and click the `administrator access and click next to review and create the user. Review and create user view user Once the user is created, click on the download .csv file to get the IAM user name and login password ** Don’t skip this ** save it, open it to get the url, username and password to login. Then click on view user on top left
  2. Click on Security credentials,click create access key on your right or scroll down and then click create an Access Key you'll need this for the CLI and Terraform
    Giving user programmatic access
    For use case, select command line access and then confirm the check box as shown below.
    Create user access keys
    Leave everything as default and then click create access key

  3. Download or copy the Access Key ID and Secret Access Key somewhere safe. You only get one chance to see the secret key.
    Remember to read the access key best practices

Download access keys

💡 What I learned when setting up the permissions : For a learning environment, AdministratorAccess is fine. In a real production setup, you'd want to follow the principle of least privilege, only granting the specific permissions Terraform actually needs. Something to keep in mind as you grow.

Set Up a Billing Alert/ Zero spend budget

Before you do anything else, set up a billing alert. AWS costs can sneak up on you, especially when you're experimenting.

  1. Go to Billing and Cost Management in the console
  2. Navigate to Budgets and create a budget
  3. Set a threshold that makes sense for you — even $0.01 or $1 is enough to get an email before things spiral

This took five minutes and has saved me from more than one surprise at the end of the month.

Lab 2: Installing and Configuring the AWS CLI

With your IAM user and access keys ready, the next step is getting the AWS CLI installed so you can interact with AWS from your terminal.

Installing the AWS CLI

The installation process varies slightly by OS:AWS provides a very good documentation for this I followed the documentation and it felt so easy to install, you can check the documentation and follow through depending with your Operating system.

Confirm aws CLI installation

Configuring the CLI

Now connect the CLI to your IAM user:
Run the following command
bash
aws configure

You'll be prompted for four things:
Open the .csv access key file you downloaded and then copy and paste in the details required.
Configure user access key and secrete access key

AWS Access Key ID [None]: YOUR_ACCESS_KEY_ID
AWS Secret Access Key [None]: YOUR_SECRET_ACCESS_KEY
Default region name [None]: us-east-1
Default output format [None]: json

Use the access key you created for your IAM user — not root credentials.
This stores your credentials in ~/.aws/credentials and your config in ~/.aws/config. You can open those files and inspect them directly if you want to see what's happening under the hood.

Verify It's Working

Test your connection with a simple command:

bash
aws sts get-caller-identity

User Credentials
If everything is configured correctly, you'll get back a JSON response showing your Account ID, User ID, and ARN. If you see your IAM user's ARN in there as shown above, you're good to go.

Lab 3: Installing Terraform and Connecting It to AWS

Installing Terraform

You can follow this official terraform documentation for easy installation

VSCode Extensions I'm Using

If you're writing Terraform in VSCode (and you should be — the experience is genuinely good), here are the extensions I installed:

  • HashiCorp Terraform for syntax highlighting, IntelliSense, and formatting for .tf files
  • AWS Toolkit — connect to AWS services directly from VSCode, browse resources, and manage credentials.
  • GitLens — Git supercharged — enhances Git functionality; it is considered essential ("non-negotiable") for managing your Terraform code, ensuring that all changes are properly tracked and controlled using version control.

Connecting Terraform to AWS

This is where it all comes together — and it's also where we learn something important about how Terraform authenticates.

How Terraform Authenticates with AWS

Terraform uses the AWS provider to interact with AWS. When you run terraform apply, it needs credentials to make API calls on your behalf. There are a few ways it can get those credentials, and understanding the order matters:

  1. Environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)
  2. Shared credentials file (~/.aws/credentials) — what aws configure set up
  3. IAM roles (when running on EC2 or in CI/CD pipelines)
  4. Hardcoded in the provider block — please don't do this this is not recommended practice as I was learning through

Because I already ran aws configure, Terraform automatically picks up my credentials from ~/.aws/credentials. No extra configuration needed in the Terraform code itself. This is the cleanest approach for local development.

Key points: What Would Happen If You Used Root Credentials?

Technically, it would work. Terraform doesn't care whether the credentials belong to root or an IAM user, it just needs valid credentials with the right permissions.

Why it's a bad idea: Root credentials are the keys to the kingdom. If those credentials were ever leaked — committed to a public GitHub repo, exposed in logs, intercepted, an attacker would have unrestricted access to your entire AWS account. They could spin up resources, exfiltrate data, rack up a massive bill, or delete everything. There's no way to scope or limit root access. You can't say "these root credentials can only touch EC2" root is Root means everything.

With an IAM user, you can:

  • Scope permissions to only what's needed
  • Rotate credentials without affecting other users or services
  • Disable or delete the user if credentials are compromised
  • Audit exactly what that user has done via CloudTrail

There's also a practical reason: AWS explicitly recommends against using root credentials for programmatic access. It's considered a security misconfiguration, and tools like AWS Security Hub will flag it.

The rule is simple: root credentials stay in the safe. IAM credentials do the work.

Finally : Common Mistakes to Avoid

A few things that can trip you up and cost you time:

  • Using root credentials in aws configure — Use your IAM user's access keys instead
  • Committing credentials to Git — Add .terraform/ and any .tfvars files containing secrets to your .gitignore from day one
  • Skipping the billing alert — Takes five minutes, potentially saves you hundreds of dollars
  • Not pinning your Terraform provider version — Using ~> 5.0 instead of just aws prevents unexpected breaking changes when the provider updates
  • Forgetting to run terraform init after adding a provider — It won't work without it; init downloads the provider plugins

Top comments (0)