Cloud 12 min read

AWS CLI First #1: Installation, Root Setup & IAM Admin User Provisioning

Master AWS from the terminal. Learn how to install AWS CLI v2, securely bootstrap from the root account with MFA, configure named profiles, and provision a dedicated CLI admin IAM user purely with CLI commands.

Mohammad Rizky Prawira

August 27, 2026

terminal Series Guide • Part 1 of 17

AWS with CLI: The Terminal-First Mastery Path

Part of the CLI-first comprehensive learning path from foundational setup to production cloud architectures.

View Full Learning Path arrow_forward

When learning Amazon Web Services (AWS), the default path for most developers is “ClickOps”—navigating through hundreds of nested pages in the AWS Management Console. While the web console is helpful for visual exploration, relying on it creates significant drawbacks:

Lack of reproducibility: You cannot easily repeat or automate 30 manual console clicks.
Slow feedback loop: Pointing and clicking slows down infrastructure inspection and debugging.
Hidden API mechanisms: The console obscures the underlying REST APIs, JSON payloads, and authorization policies that power AWS.

In this AWS with CLI series, we take a terminal-first mindset. Every resource we architect—from identity and networking to serverless microservices and container fleets—will be deployed, configured, and managed directly from our command line.

In this foundational guide, we will:

Install and configure AWS CLI v2 with shell autocompletion.
Securely bootstrap our AWS environment using the Root Account with Multi-Factor Authentication (MFA).
Generate our initial bootstrap credentials.
Configure local named CLI profiles (~/.aws/credentials & ~/.aws/config).
Provision another fully privileged Administrator IAM User purely via terminal commands—leaving the web console behind for good.

💰 Estimated Lab Cost

Component	Usage in Lab	AWS Cost
AWS CLI v2 Installation	Local Client Machine	$0.00 (Free)
AWS IAM Users, Groups & MFA	Identity & Access Management	$0.00 (100% Free)
Total Estimated Cost	Complete Hands-On Session	$0.00 (100% Free)

Architecture of AWS CLI Authentication

Before writing commands, let’s understand how your terminal communicates with AWS:

+-------------------------------------------------------------------------+
| Local Terminal / CLI Workstation                                        |
|                                                                         |
|  [ aws <service> <command> --profile dev-admin ]                        |
|                     |                                                   |
|                     v Reads                                             |
|  [ ~/.aws/credentials ] -> AWS_ACCESS_KEY_ID + AWS_SECRET_ACCESS_KEY    |
|  [ ~/.aws/config ]      -> region + output format                       |
+-------------------------------------------------------------------------+
                     |
                     | 1. Signs HTTP Request (SigV4 Protocol)
                     | 2. Sends encrypted TLS Payload to AWS Endpoint
                     v
+-------------------------------------------------------------------------+
| AWS Cloud API Gateway (e.g., https://iam.amazonaws.com)                |
|                                                                         |
|  [ AWS Identity and Access Management (IAM) ]                           |
|    -> Authenticates Access Key                                          |
|    -> Evaluates IAM Policies (AdministratorAccess)                      |
|    -> Executes API Action (e.g. CreateUser, LaunchEC2Instance)          |
+-------------------------------------------------------------------------+

Every AWS CLI execution cryptographically signs an HTTPS request using the AWS Signature Version 4 (SigV4) signing process before sending it to the respective AWS service endpoint.

Phase 1: Installing AWS CLI v2

The AWS Command Line Interface version 2 (AWS CLI v2) is the official unified tool to manage your AWS services.

1. Installation by Operating System

macOS

Using Homebrew:

brew install awscli

Or using the official macOS PKG installer:

curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"
sudo installer -pkg AWSCLIV2.pkg -target /
rm AWSCLIV2.pkg

Linux (x86_64)

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install
rm -rf aws awscliv2.zip

Windows

In PowerShell (as Administrator) or via Windows Package Manager:

winget install Amazon.AWSCLI

Or download and run the AWS CLI MSI Installer.

2. Verify Installation

Run the following command to verify that AWS CLI v2 is accessible in your system PATH:

aws --version

Expected Output:

aws-cli/2.22.x Python/3.12.x Darwin/24.x.x exe/x86_64

[!NOTE] Make sure the version starts with aws-cli/2.x. Version 1 is legacy and lacks modern credential caching and performance optimizations.

3. Enable Shell Autocompletion

Enabling autocompletion saves time by allowing you to hit <TAB> to see available services, subcommands, and parameter flags.

For Zsh (macOS / Linux):

Add the following to your ~/.zshrc:

autoload bashcompinit && bashcompinit
complete -C "$(which aws_completer)" aws

Reload your shell:

source ~/.zshrc

For Bash:

Add the following to your ~/.bashrc:

complete -C "$(which aws_completer)" aws

Core Concept: What is AWS IAM?

Before creating users and credentials, let’s understand the central backbone of AWS security: AWS Identity and Access Management (IAM).

IAM is a global, foundational AWS service that manages who can access your AWS environment and what actions they are permitted to execute. Every single AWS CLI command you run passes through the IAM evaluation engine before touching any cloud resource.

                  +----------------------------------------------+
                  |           Incoming AWS CLI Request           |
                  |     (e.g., "aws ec2 run-instances ...")      |
                  +----------------------------------------------+
                                         |
                                         v
               +----------------------------------------------------+
               | 1. Authentication (AuthN): "Who are you?"          |
               |    - Validates Access Key ID & Signature (SigV4)   |
               |    - Confirms identity: user/cloud-dev-admin       |
               +----------------------------------------------------+
                                         |
                                         v
               +----------------------------------------------------+
               | 2. Authorization (AuthZ): "What can you do?"       |
               |    - Checks attached IAM Policies                  |
               |    - Evaluates: Explicit Deny > Allow > Deny       |
               +----------------------------------------------------+
                                         |
                       +-----------------+-----------------+
                       |                                   |
                       v [Allowed]                         v [Denied]
            +----------------------+             +--------------------+
            | Execute AWS Action   |             | 403 Access Denied  |
            +----------------------+             +--------------------+

The 4 Core Primitives of IAM

To master AWS security and access management, you only need to understand four basic building blocks:

Primitive	What It Is	Primary Use Case	Lifetime
IAM User	A persistent identity representing a specific person or service	Interactive CLI workflows or local dev access	Permanent (until deleted)
IAM Group	A collection of IAM Users	Managing permissions across teams in bulk (e.g. `Admins`, `Developers`)	Permanent
IAM Role	An identity with no permanent credentials, assumed dynamically	AWS Services (EC2, Lambda), CI/CD, cross-account access	Temporary (15 min – 12 hrs)
IAM Policy	A formal JSON document granting or denying permissions	Attached directly to Users, Groups, or Roles	Reusable / Versioned

The Cardinal Rule: “Implicit Deny by Default”

In AWS, everything is denied by default. If you create a new IAM user and do not attach any policy to it, that user has zero permissions—they cannot even view their own username or list S3 buckets.

To grant access, you must explicitly attach a Policy.

Demystifying `AdministratorAccess`

When we attach the AWS-managed policy AdministratorAccess to our user, what are we actually giving them? Behind the scenes, it is simply a standard JSON permission statement:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

Effect: "Allow": Grants permission.
Action: "*": Allows every single AWS API action across all services (IAM, EC2, S3, RDS, VPC, etc.).
Resource: "*": Applies the permission across all resources and all AWS regions.

[!NOTE] For our initial learning and sandbox environment, full AdministratorAccess gives us total freedom to explore without being blocked by permissions. In Part 3, we will learn how to write custom policies enforcing the Principle of Least Privilege.

When you sign up for AWS, you receive a Root Account identified by your primary email address. The root account has unrestricted access to all resources and billing dimensions.

[!CAUTION] Cardinal Rule of AWS Security: NEVER generate access keys for the Root user and NEVER use the Root account for daily development or CLI tasks. If your root credentials leak, an attacker has total, irreversible control of your account.

We will use the Root Account exactly once via the web console to set up MFA and create our initial bootstrap IAM administrator.

Step-by-Step Root Hardening:

Open the AWS Management Console and log in with your root email.
Navigate to IAM (Identity and Access Management).
Under Security recommendations, click Add MFA (Multi-Factor Authentication) for the root user.
Select Authenticator app (Google Authenticator, 1Password, or Authy), scan the QR code, enter two consecutive TOTP codes, and enable MFA.

Phase 3: Creating the Initial Bootstrap IAM Administrator via Console

To start interacting with AWS through the CLI, we need an initial IAM user with administrative privileges and programmatic access keys.

1. Create the IAM User in the Console

In the IAM Console, click Users in the left sidebar, then click Create user.
User details:
- User name: bootstrap-admin
- Provide user access to the AWS Management Console: Unchecked (for CLI-only operations).
Set permissions:
- Select Attach policies directly.
- Search for AdministratorAccess (AWS Managed Policy) and check its box.
Click Next, review the configuration, and click Create user.

2. Generate Access Keys

Click on the newly created bootstrap-admin user.
Select the Security credentials tab.
Scroll to Access keys and click Create access key.
Select Command Line Interface (CLI) as the use case.
Check the confirmation acknowledgment checkbox and click Next.
(Optional) Set a description tag: Initial CLI bootstrap key.
Click Create access key.
CRITICAL: Copy the Access Key ID (AKIA...) and the Secret Access Key. Download the .csv file. You will not be able to view the secret key again once you leave this page.

Now, sign out of the AWS Root Console. We are going full CLI from here on.

Phase 4: Configuring AWS CLI Profiles Locally

AWS CLI stores credentials and configurations in two plain-text INI files inside your user home directory:

~/.aws/credentials: Contains secret access keys.
~/.aws/config: Contains default regions, output formats, and session settings.

Run `aws configure` with a Named Profile

Instead of using the default profile, we will create a named profile called bootstrap-admin:

aws configure --profile bootstrap-admin

Provide the requested values interactively:

AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Default region name [None]: ap-southeast-1
Default output format [None]: json

[!TIP] Choose a default region close to you or your target infrastructure. Common regions include:

us-east-1 (N. Virginia)

us-west-2 (Oregon)

ap-southeast-1 (Singapore)

eu-central-1 (Frankfurt)

Inspecting Local Configuration Files

Let’s inspect the files generated on your machine:

1. View stored credentials (keep this file secure):

cat ~/.aws/credentials

[bootstrap-admin]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

2. View profile configuration:

cat ~/.aws/config

[profile bootstrap-admin]
region = ap-southeast-1
output = json

Phase 5: Hardening Account Security via CLI Password Policy

Before creating team users, let’s enforce a strict, enterprise-grade Account Password Policy directly from our terminal.

aws iam update-account-password-policy \
  --minimum-password-length 14 \
  --require-symbols \
  --require-numbers \
  --require-uppercase-characters \
  --require-lowercase-characters \
  --allow-users-to-change-password \
  --profile bootstrap-admin

Verify the active policy:

aws iam get-account-password-policy --profile bootstrap-admin --output table

Phase 6: Verifying CLI Identity with AWS STS

To verify that your credentials work and AWS recognizes your permissions, use the AWS Security Token Service (STS):

aws sts get-caller-identity --profile bootstrap-admin --output table

Output:

---------------------------------------------------------------------------------
|                               GetCallerIdentity                               |
+--------------+------------------------------------+---------------------------+
|   Account    |                Arn                 |          UserId           |
+--------------+------------------------------------+---------------------------+
| 123456789012 | arn:aws:iam::123456789012:user/bootstrap-admin | AIDAXXXXXXXXXXXXXXXXX     |
+--------------+------------------------------------+---------------------------+

Notice the output:

Account: Your 12-digit AWS Account ID.
Arn: The Amazon Resource Name showing you are authenticated as user/bootstrap-admin.
UserId: The unique IAM identifier.

Phase 7: Provisioning Admin IAM Group & User Purely via CLI

In production AWS environments, attaching policies directly to individual users is an anti-pattern. Instead, AWS recommends using IAM Groups:

You attach permissions once to the Group.
Any user placed into the group immediately inherits its policies.
When team members change roles or depart, managing access is as simple as adding or removing them from the group.

           +-------------------------------------------------------------+
           |                 AWS CLI Workflow Execution                  |
           +-------------------------------------------------------------+
                                          |
          1. aws iam create-group         v
          ------------------------> [ Create Group 'Administrators' ]
                                          |
          2. aws iam attach-group-policy  v
          ------------------------> [ Attach 'AdministratorAccess' to Group ]
                                          |
          3. aws iam create-user          v
          ------------------------> [ Create IAM User 'cloud-dev-admin' ]
                                          |
          4. aws iam add-user-to-group    v
          ------------------------> [ Add 'cloud-dev-admin' to 'Administrators' ]
                                          |
          5. aws iam create-access-key    v
          ------------------------> [ Generate New Key Pair for CLI ]

Step 1: Create the `Administrators` IAM Group

aws iam create-group \
  --group-name Administrators \
  --profile bootstrap-admin

Step 2: Attach the Administrator Policy to the Group

We attach the AWS-managed policy AdministratorAccess to the Group:

aws iam attach-group-policy \
  --group-name Administrators \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess \
  --profile bootstrap-admin

Step 3: Create the User `cloud-dev-admin`

aws iam create-user \
  --user-name cloud-dev-admin \
  --profile bootstrap-admin

JSON Output:

{
    "User": {
        "Path": "/",
        "UserName": "cloud-dev-admin",
        "UserId": "AIDA4EXAMPLEUNIQUEID",
        "Arn": "arn:aws:iam::123456789012:user/cloud-dev-admin",
        "CreateDate": "2026-08-27T11:15:00+00:00"
    }
}

Step 4: Add `cloud-dev-admin` to the `Administrators` Group

aws iam add-user-to-group \
  --user-name cloud-dev-admin \
  --group-name Administrators \
  --profile bootstrap-admin

Verify that the group membership and policy inheritance are active:

aws iam get-group \
  --group-name Administrators \
  --profile bootstrap-admin \
  --output table

Step 5: Generate Access Keys via CLI

Now, let’s create a new programmatic Access Key for cloud-dev-admin:

aws iam create-access-key \
  --user-name cloud-dev-admin \
  --profile bootstrap-admin \
  --output json

Response:

{
    "AccessKey": {
        "UserName": "cloud-dev-admin",
        "AccessKeyId": "AKIAEXAMPLE2NEWKEYID",
        "Status": "Active",
        "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYNEWSECRETKEY",
        "CreateDate": "2026-08-27T11:20:00+00:00"
    }
}

[!IMPORTANT] Save the AccessKeyId and SecretAccessKey values.

Step 6: Configure the New Profile

We can configure the profile directly using aws configure:

aws configure set aws_access_key_id "AKIAEXAMPLE2NEWKEYID" --profile cloud-dev-admin
aws configure set aws_secret_access_key "wJalrXUtnFEMI/K7MDENG/bPxRfiCYNEWSECRETKEY" --profile cloud-dev-admin
aws configure set region "ap-southeast-1" --profile cloud-dev-admin
aws configure set output "json" --profile cloud-dev-admin

Let’s verify the updated ~/.aws/credentials:

cat ~/.aws/credentials

[bootstrap-admin]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

[cloud-dev-admin]
aws_access_key_id = AKIAEXAMPLE2NEWKEYID
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYNEWSECRETKEY

Phase 7: Switching Profiles & Testing Operations

Instead of passing --profile cloud-dev-admin to every single command, you can set the AWS_PROFILE environment variable in your terminal session.

1. Set the Active Session Profile

export AWS_PROFILE=cloud-dev-admin

2. Verify Your Active Identity

aws sts get-caller-identity --output table

Output:

---------------------------------------------------------------------------------
|                               GetCallerIdentity                               |
+--------------+------------------------------------+---------------------------+
|   Account    |                Arn                 |          UserId           |
+--------------+------------------------------------+---------------------------+
| 123456789012 | arn:aws:iam::123456789012:user/cloud-dev-admin | AIDA4EXAMPLEUNIQUEID      |
+--------------+------------------------------------+---------------------------+

3. Test Administrative API Calls

List all IAM users in the account:

aws iam list-users --output table

Check available AWS regions:

aws ec2 describe-regions --query "Regions[].RegionName" --output table

Check the status of S3 object storage in your account:

aws s3 ls

You now have a fully functional administrator user operating seamlessly from your terminal.

Phase 8: Security Best Practices for CLI Learners

When building a CLI-first habit, incorporate these safety rules into your daily routine:

Keep ~/.aws permissions restricted: Ensure only your user account can read your credentials:
```
chmod 600 ~/.aws/credentials
chmod 600 ~/.aws/config
chmod 700 ~/.aws
```
Never commit credentials to Git: Ensure .gitignore contains:
```
.aws/
*.pem
*.csv
.env
.env.local
```

Deactivate or Rotate Stale Keys: If you ever need to disable an access key without deleting it:

aws iam update-access-key \
  --access-key-id AKIAIOSFODNN7EXAMPLE \
  --status Inactive

Delete Unneeded Keys:

aws iam delete-access-key \
  --user-name bootstrap-admin \
  --access-key-id AKIAIOSFODNN7EXAMPLE

Quick Reference: Essential IAM CLI Commands

Action	CLI Command
Check Identity	`aws sts get-caller-identity`
Set Password Policy	`aws iam update-account-password-policy --minimum-password-length 14 --require-symbols --require-numbers`
Create Group	`aws iam create-group --group-name <name>`
Attach Policy to Group	`aws iam attach-group-policy --group-name <group> --policy-arn <arn>`
Add User to Group	`aws iam add-user-to-group --user-name <user> --group-name <group>`
Create User	`aws iam create-user --user-name <name>`
List Users	`aws iam list-users --output table`
Create Access Key	`aws iam create-access-key --user-name <name>`
List Access Keys	`aws iam list-access-keys --user-name <name>`
Deactivate Key	`aws iam update-access-key --access-key-id <id> --status Inactive`

Summary & What’s Next

Congratulations! You have taken the first decisive step into the AWS CLI First paradigm:

You installed and verified AWS CLI v2 with intelligent shell autocompletion.
You secured your Root Account with MFA and safely avoided using root keys.
You created an initial bootstrap user and configured isolated named profiles in ~/.aws/.
You provisioned a second IAM administrator (cloud-dev-admin) with full permissions purely using terminal commands.

In Part 2, we will dive into Multi-Account Profiles, AWS STS AssumeRole, and MFA-Enforced Temporary Session Tokens, learning how enterprise engineers switch roles dynamically across staging and production without hardcoding static long-lived keys.