Summary:

  • Master AWS CLI v2 installation across Linux (glibc 2.17+), macOS, Windows, and ARM64 architectures with version-specific guidance.
  • Understand critical behavioral differences between AWS CLI v1 and v2, including regional STS endpoints, binary format changes, and pagination defaults that affect production scripts.
  • Configure secure authentication using IAM Identity Center (SSO), manage multiple profiles, and implement credential best practices for both development and CI/CD pipelines.
  • Execute essential commands for S3, EC2, IAM, and Lambda with modern output formatting options and automation-ready scripting patterns.

Every cloud engineer eventually reaches a moment where clicking through the AWS Console becomes the bottleneck. Whether you are provisioning infrastructure at scale, automating deployments, or simply tired of navigating endless browser tabs, the AWS Command Line Interface transforms how you interact with Amazon Web Services. This AWS CLI tutorial for beginners walks you through installation, configuration, and practical command execution while addressing the nuanced changes in AWS CLI version 2 that most guides overlook. By the end, you will understand not just the how but the why behind modern CLI practices that separate junior administrators from seasoned cloud professionals.

The AWS CLI converts terminal commands into authenticated API requests to manage AWS services

Understanding AWS CLI and why version 2 matters

The AWS Command Line Interface is a unified tool that provides a consistent interface for interacting with all parts of Amazon Web Services. Rather than navigating the web console for each service, you execute commands directly from your terminal. This enables scripting, automation, and integration with CI/CD pipelines. AWS CLI version 2 represents a significant evolution from its predecessor, introducing architectural changes that affect everything from installation methods to default behaviors in production environments.

Version 2 ships as a self-contained binary with its own embedded Python interpreter, eliminating the dependency conflicts that plagued version 1 installations. This architectural shift means you no longer need to manage Python versions or virtual environments for CLI operations. However, this change also introduced new system requirements, particularly around glibc compatibility on Linux systems, that catch many beginners off guard during installation.

Key differences between AWS CLI v1 and v2

Understanding the behavioral differences between versions is critical before installation, especially if you are inheriting existing automation or working in mixed environments. The following comparison table highlights changes that directly impact daily operations and script compatibility. These differences reflect AWS’s push toward more secure defaults and improved performance characteristics.

FeatureAWS CLI v1AWS CLI v2
Installation methodPython pip packageSelf-contained binary installer
Python dependencyRequires system Python 2.7+ or 3.4+Embedded interpreter, no external dependency
STS endpoint defaultGlobal endpoint (sts.amazonaws.com)Regional endpoints (sts.region.amazonaws.com)
S3 addressing stylePath-style defaultVirtual-hosted style default
Binary parameter handlingPasses binary as-isBase64-encodes by default (cli_binary_format)
Output paginationReturns all resultsClient-side pagination with cli_pager
SSO supportNot nativeBuilt-in aws configure sso
Auto-promptNot availableInteractive command wizard

The shift to regional STS endpoints deserves particular attention. AWS made this change to improve request latency and align with Signature v4 regional signing requirements. Scripts that explicitly relied on the global endpoint or made assumptions about token formats may require updates. Consider these implications when planning your migration strategy.

Installing AWS CLI v2 across platforms

Installation procedures vary significantly across operating systems, and AWS CLI v2 introduces specific system requirements that differ from the pip-based v1 approach. The self-contained binary approach simplifies dependency management but requires attention to architecture compatibility. This is particularly true on Linux systems where glibc versions determine installation success.

Linux installation with glibc requirements

Linux installations require glibc version 2.17 or later, which corresponds to distributions released after 2012. This requirement stems from the compiled binary’s dependencies and affects older enterprise distributions still running in production environments. Before installation, verify your glibc version using the command ldd --version to confirm compatibility.

The installation process for x86_64 Linux systems follows these steps:

  1. Download the installer package: curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
  2. Unzip the package: unzip awscliv2.zip
  3. Run the installer with appropriate permissions: sudo ./aws/install
  4. Verify installation: aws --version

Watch out: ARM64 Linux systems (including AWS Graviton instances) require a different installer package. Use the URL https://awscli.amazonaws.com/awscli-exe-linux-aarch64.zip for ARM-based architectures to avoid binary incompatibility errors.

macOS and Windows installation

macOS users benefit from a streamlined pkg installer that handles path configuration automatically. Download the installer from the official AWS CLI installation guide and run the standard macOS installation workflow. The installer supports both Intel and Apple Silicon architectures through a universal binary, eliminating architecture-specific download requirements.

Windows installation offers two approaches depending on your environment preferences. The MSI installer provides a traditional Windows installation experience with automatic PATH configuration. Alternatively, Windows Subsystem for Linux users can follow the Linux installation procedure within their WSL distribution. For PowerShell-centric workflows, the MSI approach integrates more naturally with Windows command environments.

aws-cli-installation-flowchart
Installation decision tree for AWS CLI v2 across different operating systems and architectures

Configuring AWS CLI for secure access

Configuration establishes the authentication and default settings that govern all CLI operations. AWS CLI stores configuration in two files within your home directory. The ~/.aws/credentials file holds sensitive authentication data, while ~/.aws/config contains behavioral settings. Understanding this separation helps you manage credentials securely while customizing CLI behavior for different use cases.

Basic configuration with aws configure

The quickest path to a working configuration uses the interactive aws configure command, which prompts for four essential values. You will need your AWS Access Key ID, Secret Access Key, default region, and preferred output format. This information creates a default profile that applies to all commands unless you specify an alternative.

Execute aws configure and provide the requested values:

  • AWS Access Key ID: The identifier from your IAM user credentials
  • AWS Secret Access Key: The secret paired with your access key
  • Default region name: Your preferred AWS region (e.g., us-east-1, eu-west-2)
  • Default output format: Choose json, table, or text based on your workflow

Pro tip: Never use root account credentials for CLI access. Create dedicated IAM users with least-privilege permissions, and rotate access keys every 90 days as recommended by AWS security best practices.

Configuring SSO authentication

AWS IAM Identity Center (formerly AWS SSO) provides a more secure authentication model that eliminates long-lived access keys. The aws configure sso command initiates an interactive wizard that establishes browser-based authentication with automatic token refresh. This approach aligns with enterprise security requirements and reduces credential exposure risks.

The SSO configuration process creates a named profile linked to your identity provider. When you run commands with this profile, the CLI automatically handles token acquisition and refresh through your configured SSO portal. Session tokens typically expire after one hour but refresh transparently during active use, addressing the session token expiry concerns that affect long-running automation.

Managing multiple profiles

Real-world AWS usage typically involves multiple accounts for development, staging, and production environments. Named profiles allow you to maintain separate configurations and switch between them using the --profile flag or the AWS_PROFILE environment variable. This capability proves essential for consultants working across client accounts or teams managing environment isolation.

Create additional profiles by running aws configure --profile profile-name and providing the appropriate credentials. Your config file supports extensive customization per profile, including region overrides, output format preferences, and CLI-specific settings like cli_pager and cli_binary_format. The following example demonstrates a multi-profile configuration structure:

# ~/.aws/config

[default]

region = us-east-1 output = json

[profile development]

region = us-west-2 output = table cli_pager =

[profile production]

region = us-east-1 output = json cli_binary_format = raw-in-base64-out

Essential AWS CLI commands for daily operations

Mastering core commands across frequently used services establishes the foundation for effective CLI usage. The command structure follows a consistent pattern: aws [service] [operation] [parameters]. This predictability means learning one service’s command patterns transfers directly to others, accelerating your proficiency across the AWS ecosystem.

Installation decision tree for AWS CLI v2 across different operating systems and architectures

S3 operations for object storage

Amazon S3 commands divide into two categories. High-level aws s3 commands handle common operations, while low-level aws s3api commands provide granular control. The high-level commands like cp, sync, and ls handle multipart uploads and recursive operations automatically, making them ideal for most use cases.

Common S3 operations include:

  • List buckets: aws s3 ls
  • Upload file: aws s3 cp localfile.txt s3://bucket-name/path/
  • Sync directories: aws s3 sync ./local-dir s3://bucket-name/prefix --delete
  • Download recursively: aws s3 cp s3://bucket-name/prefix ./local-dir --recursive

Historical note: AWS CLI v2 changed the default S3 addressing style from path-style to virtual-hosted style. This change aligns with AWS’s deprecation of path-style URLs for new buckets created after September 2020, though existing buckets retain backward compatibility.

EC2 instance management

EC2 commands enable complete instance lifecycle management from launch to termination. The describe-instances command with JMESPath queries becomes particularly powerful for extracting specific information from complex response structures. Understanding output filtering transforms verbose JSON responses into actionable data.

Launch a new instance with explicit parameters:

Query running instances with filtered output:

IAM and security operations

IAM commands manage the identity and access layer that governs all AWS interactions. These commands require careful attention because misconfiguration can lock out users or expose resources. Always test IAM changes in non-production environments and maintain break-glass procedures for emergency access recovery.

Essential IAM operations for administrators:

  • List users: aws iam list-users --output table
  • Create access key: aws iam create-access-key --user-name username
  • Attach policy: aws iam attach-user-policy --user-name username --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess
  • Get caller identity: aws sts get-caller-identity

Advanced features and automation patterns

Beyond basic commands, AWS CLI v2 introduces features that enhance productivity and enable sophisticated automation. These capabilities distinguish casual users from professionals who leverage the CLI as a primary infrastructure management tool. Understanding these features prepares you for CI/CD integration and complex scripting scenarios.

Output formats and the cli_pager setting

AWS CLI supports several output formats. JSON works well for programmatic parsing, table format improves human readability, and text format simplifies scripting with tools like awk and cut. Modern versions of v2 also support yaml, yaml-stream, and an off option (which is highly useful for suppressing sensitive output in CI/CD logs). Version 2 introduced automatic pagination through the cli_pager setting, which pipes long outputs through a pager program like less. While helpful for interactive use, this behavior breaks scripts that expect direct output.

Disable the pager for automation by setting cli_pager= (empty value) in your config file or exporting AWS_PAGER="" in your shell environment. This configuration ensures command output flows directly to stdout for pipeline processing. The following demonstrates output format selection for different use cases:

Watch out: The cli_binary_format setting affects how binary parameters are passed to AWS services. Version 2 defaults to base64 encoding, which breaks scripts that pass raw binary data. Set cli_binary_format=raw-in-base64-out to restore v1 behavior when needed.

Auto-prompt and command discovery

The auto-prompt feature provides an interactive command-building experience that suggests parameters and validates input as you type. Enable it with aws --cli-auto-prompt or set cli_auto_prompt=on-partial in your configuration. This feature accelerates learning by exposing available options without constant documentation reference.

CI/CD integration patterns

Integrating AWS CLI into continuous integration pipelines requires attention to credential management and exit code handling. Version 2 returns consistent exit codes. It returns 0 for success, 1 for S3 transfer failures, 2 for command parsing errors, 130 for SIGINT interruption, 254 for service-side errors, and 255 for general command errors. These specific codes enable reliable and targeted error handling in automation scripts.

For CI/CD environments, prefer IAM roles over access keys when running on AWS infrastructure like CodeBuild or EC2. The CLI automatically retrieves credentials from the instance metadata service, eliminating credential storage in pipeline configurations. For external CI systems, use OIDC federation to exchange platform tokens for temporary AWS credentials.

aws-cli-cicd-integration
AWS CLI integration pattern for CI/CD pipelines using IAM roles and OIDC federation

Troubleshooting common issues

Even experienced users encounter CLI issues that require systematic debugging. Understanding common failure patterns and their resolutions accelerates problem resolution and reduces frustration during critical operations. The following scenarios represent the most frequent issues reported by AWS CLI users.

Credential and authentication errors typically manifest as AccessDenied or InvalidClientTokenId messages. Verify your active credentials with aws sts get-caller-identity to confirm which identity the CLI is using. Check for conflicting environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) that might override your intended profile configuration.

Pro tip: Enable debug logging with aws --debug [command] to see the complete request and response cycle. This output reveals credential resolution order, endpoint selection, and the exact API calls being made. It is invaluable for diagnosing unexpected behavior.

Region endpoint issues often stem from the v2 default of regional STS endpoints. If your scripts fail with signature errors or unexpected region behavior, explicitly set sts_regional_endpoints=legacy in your config to restore global endpoint behavior while you update your automation. For S3 operations, bucket region mismatches cause redirect errors that the CLI usually handles automatically. However, cross-region operations may require explicit --region flags.

Conclusion

Mastering AWS CLI transforms your cloud operations from manual console navigation to scriptable, repeatable infrastructure management. The key takeaways from this tutorial center on three areas. First, understand the architectural and behavioral differences in version 2 that affect installation and script compatibility. Second, configure secure authentication through SSO and proper credential management. Third, leverage advanced features like output formatting and auto-prompt for efficient daily operations.

As AWS continues evolving its CLI tooling, expect deeper integration with services like CloudShell and expanded SSO capabilities. The patterns you establish now for credential management and automation will scale with your infrastructure complexity. Start with the basic commands covered here, progressively incorporate JMESPath queries for output filtering, and build toward fully automated infrastructure pipelines that treat AWS CLI as a first-class deployment tool.