aws/aws-cli: v1 Is in Maintenance Mode, and What That Means for Your Pipelines

What aws-cli v1 actually is, and who still needs it

The repository at aws/aws-cli provides a unified command line interface to Amazon Web Services. The README is explicit that this README is for version 1 and points readers to the v2 branch for version 2. So the question is not whether the CLI is useful, it is whether this specific major version still is.

The answer changed on August 5, 2026. According to the README, AWS CLI v1 entered maintenance mode on that date and will reach end-of-support on July 15, 2027. During maintenance mode, AWS limits releases to critical bug fixes and security issues only. The CLI will not receive API updates for new or existing services, and it will not be updated to support new regions. That is the whole story of this repository right now.

Who is it for? Teams with existing automation that calls the aws binary from shell scripts, CI jobs or cron entries, and who have not yet moved to v2. The entry points shipped by setup.py are bin/aws, bin/aws.cmd, bin/aws_completer, bin/aws_zsh_completer.sh and bin/aws_bash_completer, so anything that shells out to aws will keep working until the support window closes. New projects have no reason to start here.

How the v1 CLI is put together

This is a Python package. setup.py declares the distribution name as awscli, reads the version from awscli/__init__.py, and lists a set of pinned dependencies: docutils, PyYAML, colorama, rsa, jmespath, python-dateutil and urllib3. Because those bounds are tight (PyYAML below 6.1, colorama below 0.4.7, rsa below 4.8), the install resolves against a narrow window, which is the practical reason the README pushes virtualenv so hard.

There is an optional extra. setup.py defines extras_require with crt mapped to awscrt==0.36.0, so installing with that extra pulls the AWS Common Runtime. Nothing in the README excerpt explains when the CRT path is selected, so treat that as an implementation detail rather than a switch you flip.

Configuration is file-driven. The README lists five ways to supply credentials: the configuration command, environment variables, the shared credentials file, the config file, and an IAM role. The last one is called out as highly recommended on an EC2 instance. Profiles let you keep several identities side by side, selected with --profile, and the default profile is used when none is given. One detail trips people up: in the config file, every section other than default must prefix the profile name with the word profile, so a profile called testing is written as [profile testing]. The shared credentials file does not use that prefix.

Installing aws-cli v1 and running a first command

The README recommends pip 9.0.2 or greater and setuptools 36.2.0 or greater, and says the safest route is pip inside a virtualenv. The package name is awscli.

$ python -m pip install awscli

If you are not in a virtualenv, the README gives two alternatives: sudo python -m pip install awscli for a global install, or python -m pip install --user awscli for a per-user install. Upgrading an existing install is python -m pip install --upgrade awscli. On macOS, if you hit an error about the version of six that shipped with distutils in El Capitan, the README says to add --ignore-installed six. On Linux and macOS a bundled installer is documented, and Windows has an MSI installer; both are linked from the AWS CLI User Guide rather than described in the repository.

After installation, configure credentials. The README calls aws configure the quickest way to get started.

$ aws configure
AWS Access Key ID: MYACCESSKEY
AWS Secret Access Key: MYSECRETKEY
Default region name [us-west-2]: us-west-2
Default output format [None]: json

The prompts are shown in the README exactly as above, with the region defaulting to us-west-2 and the output format defaulting to None until you type one. If you prefer environment variables, export AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY instead. For a shared credentials file, create an INI file with a [default] or named section holding aws_access_key_id and aws_secret_access_key, and place it at ~/.aws/credentials, or at %UserProfile%\.aws/credentials on Windows. To keep it elsewhere, set AWS_SHARED_CREDENTIALS_FILE to the path. The config file works the same way at ~/.aws/config, with AWS_CONFIG_FILE as the override, and its non-default sections need the [profile name] header form.

The limitation that decides everything: no new APIs, no new regions

Maintenance mode is not a vague warning. The README states the consequences plainly: releases are limited to critical bug fixes and security issues, the CLI will not receive API updates for new or existing services, and it will not be updated to support new regions. If your workflow depends on a service feature launched after August 5, 2026, v1 is the wrong tool, and no amount of pinning will fix that.

There is a second, quieter failure mode in the dependency pins. The install_requires list in setup.py caps PyYAML, colorama, rsa and urllib3 below specific versions. Those caps exist to keep a maintenance-mode branch stable, but they also mean that a transitive dependency bump elsewhere in your environment can force a resolver conflict. The README's advice to use a virtualenv is doing real work here, not just being tidy.

Python support has already moved once. The README notes that support for Python 3.9 ended on 2026-04-29, following the Python Software Foundation end of support for that runtime on 2025-10-31. The supported set is now 3.10 through 3.14. setup.py encodes the floor as python_requires >= 3.10. If you are still on 3.9, the package will refuse to install rather than fail at runtime, which is at least a clear signal.

AWS CLI v2 is the migration target, not a side-by-side alternative

The README does not present v2 as a competing tool. It says to migrate to AWS CLI v2 and links a migration guide, a maintenance mode announcement, and a note about dependency version updates. The v2 source lives on the v2 branch of the same repository, so this is a major-version move within one project rather than a switch to a different vendor.

The practical difference for a reader deciding today is scope. v2 is the branch that continues to receive service and region updates; v1 is the branch that will not. The README does not enumerate behavioral differences between the two, so anyone planning a migration should read the linked migration guide rather than assume the command surface is identical.

If you want something that is not the AWS CLI at all, this repository gives you nothing to compare against. It documents one interface and one migration path. Choosing a different toolchain is a decision made outside this material.

Maintenance and upgrade cost, and the licence question

The upgrade cost is asymmetric. Staying on v1 costs nothing today and everything after July 15, 2027, when end-of-support arrives. Moving to v2 costs the migration work now. The README gives no rollback instructions and does not document a downgrade path, so the migration guide is the only procedure the project points to.

On licensing, setup.py declares license="Apache License 2.0" and carries the classifier OSI Approved :: Apache Software License, while the repository metadata reports the licence as NOASSERTION. The LICENSE.txt file exists at the top level. Apache 2.0 is permissive, but this is a description of what the files say, not legal advice; if your organisation has a licence review process, run the actual LICENSE.txt through it rather than relying on the classifier string.

Development activity is visible in the repository layout. There is a .changes/ directory for changelog fragments, a CHANGELOG.rst, a CONTRIBUTING.md with a Development Version section referenced by the README, and a pyproject.toml configuring pytest markers, isort, and ruff with line-length 79 and target-version py310. The last push to the repository was on 2026-09-21. None of that changes the API freeze described in the README.

Editorial conclusion

Adopt aws-cli v1 only if you are pinned to a Python 3.10 to 3.14 environment and accept that no new service APIs or regions will arrive; everyone else should install v2. Before migrating, check which profiles, shared credentials files and AWS_CONFIG_FILE overrides your scripts depend on, because v1 and v2 read the same files but the v1 package will stop receiving API updates after July 15, 2027.

Frequently asked questions

Official sources

1. aws/aws-cli on GitHub
2. Issues
3. README
4. Releases