1. 从零到一AWS CLI 的安装与环境准备如果你正在接触 AWS无论是为了个人项目、公司业务还是准备 AWS 认证那么 AWS CLI 绝对是你绕不开的核心工具。它远不止是一个简单的命令行工具而是你与整个 AWS 云服务进行高效、自动化交互的“瑞士军刀”。想象一下你不再需要频繁登录网页控制台点击层层菜单去启动一个 EC2 实例或查看 S3 存储桶取而代之的是一行命令就能搞定并且可以轻松地嵌入脚本实现复杂的部署流程和运维自动化。这就是 AWS CLI 带来的根本性效率提升。很多人包括早期的我都曾把它想得太简单以为pip install awscli就万事大吉。结果在实际操作中遇到了权限混乱、配置冲突、命令版本不匹配等一系列头疼的问题。今天我就结合自己多年的使用和踩坑经验带你从最基础的安装配置开始深入到几个高频、实用的实战场景让你不仅能“跑起来”更能“用得好”理解其背后的设计逻辑避免那些常见的陷阱。首先我们得把 AWS CLI 请到你的电脑上。目前主流是 AWS CLI 版本 2它比 v1 功能更全、性能更好并且是 AWS 官方持续维护的版本。安装方法根据你的操作系统有所不同在 macOS 上最推荐使用 Homebrew这是最干净、最易于管理的方式。brew install awscli安装完成后在终端输入aws --version验证。如果之前装过 v1Homebrew 会帮你自动升级替换。在 Linux 上对于大多数发行版可以使用包管理器比如在 Ubuntu/Debian 上sudo apt update sudo apt install awscli但包管理器里的版本可能不是最新的。如果你想安装最新版通常需要下载 AWS 官方提供的捆绑安装包使用curl命令来安装。具体命令建议查阅 AWS 官方文档因为下载链接可能会更新。在 Windows 上最简便的方法是下载官方的 MSI 安装程序图形化界面下一步到底即可。对于习惯包管理的用户如果安装了 Chocolatey也可以使用choco install awscli来安装。注意一个常见的坑是系统里同时存在多个版本的 AWS CLI比如通过 pip、系统包、手动安装等多种方式混装。这会导致命令执行时调用错误的版本出现诡异的问题。在安装前最好先用which awsLinux/macOS或where awsWindows检查一下是否已有旧版本并考虑彻底卸载。安装只是第一步接下来才是关键——配置。这决定了你的 CLI 是否有权限、以及以何种身份去操作你的 AWS 资源。2. 核心配置详解身份、区域与输出格式配置 AWS CLI 的核心命令是aws configure。这个交互式命令会引导你输入四个关键信息它们将被保存在~/.aws/credentials和~/.aws/config文件里Windows 在C:\Users\用户名\.aws\目录下。当你运行aws configure后会依次提示AWS Access Key IDAWS Secret Access KeyDefault region nameDefault output formatAccess Key ID 和 Secret Access Key是你的“数字钥匙”。绝对不要使用 AWS 账户的根用户Root User的访问密钥这太危险了等同于把银行主账户的密码放在脚本里。正确的做法是为 CLI 的使用创建一个专门的IAM 用户。进入 AWS IAM 控制台创建一个新用户比如命名为cli-user。在权限设置上遵循最小权限原则不要直接附加 AdministratorAccess 这种全能策略。根据这个用户的实际任务创建自定义策略或选择现有的精细策略。例如如果它只负责操作 S3就只赋予 S3 相关的权限。创建用户成功后AWS 会提供一次性的 Access Key ID 和 Secret Access Key务必立即下载保存好.csv文件因为 Secret Key 一旦关闭页面就无法再次查看。Default region name是你希望默认操作的 AWS 区域例如us-east-1美国东部弗吉尼亚、ap-southeast-1新加坡或cn-north-1中国北京。这个设置非常重要因为绝大多数 AWS 服务是区域性的。如果你不指定区域CLI 就会使用这个默认值。很多新手在配置时随便填了一个区域之后执行命令发现资源找不到就是因为资源创建在了另一个区域。Default output format决定了命令返回结果的展示形式。主要有四种json 最详细、最结构化的格式适合程序解析也是默认格式。但对于人眼阅读数据量大时会显得杂乱。text 以制表符分隔的简单文本适合用grep、awk等 Unix 工具进行快速过滤。table 以 ASCII 表格形式输出非常美观适合在终端中直接查看列表类信息如列出所有 EC2 实例。yaml 另一种结构化格式可读性比 JSON 稍好。我的个人习惯是将默认输出设为table因为在日常巡查、列表查看时非常直观。当需要编写脚本或深入分析时再通过--output json参数临时指定 JSON 格式。配置完成后强烈建议运行一个简单的命令来测试配置是否生效例如aws sts get-caller-identity这个命令不需要任何特殊权限它会返回当前配置所使用的 IAM 用户或角色的 ARN、用户 ID 和账户 ID是验证身份最安全快捷的方式。3. 多环境配置与凭证管理实战在实际工作中你几乎不可能只操作一个 AWS 账户或一个环境。常见的场景包括开发Dev、测试Test、生产Prod三个独立的 AWS 账户或者个人账户与公司账户分离。如果每次都通过aws configure修改默认配置不仅麻烦而且极易出错比如误在生产环境执行了删除操作。AWS CLI 提供了优雅的Profile配置概要文件机制来解决这个问题。你可以在~/.aws/config和~/.aws/credentials文件中定义多个配置段。创建多 Profile使用aws configure --profile profile-name来为不同环境创建独立的配置。aws configure --profile dev aws configure --profile prod这样你的~/.aws/credentials文件里就会有不同的密钥段[default] aws_access_key_id AKIAIOSFODNN7EXAMPLE aws_secret_access_key wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY [dev] aws_access_key_id AKIAI44QH8DHBEXAMPLE aws_secret_access_key je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY [prod] aws_access_key_id AKIAIOSFODNN7EXAMPLE2 aws_secret_access_key wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY2而~/.aws/config文件则包含区域和输出格式等设置[default] region us-west-2 output table [profile dev] region us-east-1 output json [profile prod] region eu-central-1 output json注意在config文件中非 default 的 profile 名称前必须加上profile前缀如[profile dev]这是一个非常容易写错的细节。使用指定 Profile在执行任何 CLI 命令时通过--profile参数指定使用哪个配置。aws s3 ls --profile dev # 列出开发账户的S3桶 aws ec2 describe-instances --profile prod # 查看生产账户的EC2实例更安全的凭证管理使用 IAM 角色和 SSO对于企业级应用长期将 Access Key 保存在本地文件仍然有泄露风险。更佳实践是IAM 角色 在 EC2 实例或 Lambda 函数中直接为其附加 IAM 角色这些服务内的 AWS CLI 会自动获取临时安全凭证无需本地配置密钥。AWS Single Sign-On (SSO) 这是目前管理多账户访问最推荐的方式。你只需在本地配置一次 SSOaws configure sso它会引导你登录企业身份源然后你可以选择要访问的账户和角色。CLI 会自动管理短期令牌的刷新你完全不需要接触 Access Key。这是安全性最高、体验最好的方式尤其适合需要频繁切换多个账户的团队。4. 高频服务实战EC2、S3 与 CloudWatch 操作解析配置妥当后我们进入实战环节。AWS 有上百个服务我们挑三个最常用、也最能体现 CLI 价值的服务来深入操作。4.1 EC2 实例的生命周期管理EC2 是 AWS 的弹性计算核心。通过 CLI 管理 EC2你可以实现脚本化的实例启停、创建镜像等。列出所有实例aws ec2 describe-instances这个命令返回的 JSON 非常庞大。我强烈建议第一次使用时加上--output table并配合查询来聚焦信息。例如只查看实例ID、状态、类型和私有IPaws ec2 describe-instances \ --query Reservations[*].Instances[*].[InstanceId, State.Name, InstanceType, PrivateIpAddress] \ --output table这里的--query参数使用了 JMESPath 查询语言它是过滤和提取 CLI 返回 JSON 数据的利器必须掌握。启动一个新实例启动实例需要指定许多参数AMI ID、实例类型、密钥对、安全组等。通常我会先准备好一个 JSON 或文本文件作为--cli-input-json参数这样比在命令行拼接一长串参数更清晰、可复用。aws ec2 run-instances \ --image-id ami-0abcdef1234567890 \ --instance-type t3.micro \ --key-name MyKeyPair \ --security-group-ids sg-0abcdef1234567890 \ --subnet-id subnet-0abcdef1234567890 \ --count 1实操心得在非默认 VPC 中启动实例时必须指定--subnet-id否则会失败。安全组 ID 和子网 ID 可以通过aws ec2 describe-security-groups和aws ec2 describe-subnets命令先查询获取。停止和终止实例aws ec2 stop-instances --instance-ids i-1234567890abcdef0 aws ec2 terminate-instances --instance-ids i-1234567890abcdef0切记stop是关机计费暂停仅部分资源terminate是销毁实例及其根卷默认数据将永久丢失无法恢复。执行terminate前务必三思最好先为重要实例创建 AMI 镜像备份。4.2 S3 存储桶的自动化操作S3 是对象存储的标杆。CLI 使得上传、下载、同步大量文件变得极其高效。基本文件操作# 上传文件 aws s3 cp ./local-file.txt s3://my-bucket/path/to/file.txt # 下载文件 aws s3 cp s3://my-bucket/path/to/file.txt ./downloaded-file.txt # 递归同步整个目录增量只传输变化的文件 aws s3 sync ./local-folder s3://my-bucket/path/to/folder/ # 删除文件 aws s3 rm s3://my-bucket/path/to/file.txt # 递归删除目录下所有文件 aws s3 rm s3://my-bucket/path/to/folder/ --recursivesync命令是我最常用的命令之一它比简单的cp更智能常用于静态网站部署、日志备份等场景。管理存储桶# 列出所有桶 aws s3 ls # 列出桶内内容类似 ls -la aws s3 ls s3://my-bucket --recursive --human-readable # 创建桶桶名必须全球唯一 aws s3 mb s3://my-unique-bucket-name # 删除空桶 aws s3 rb s3://my-bucket # 强制删除非空桶极其危险 aws s3 rb s3://my-bucket --force重要警告aws s3 rb --force会删除桶及其内部所有文件且无法撤销。生产环境中执行此命令前必须有严格的审批和复核流程最好在命令前加上--dryrun参数先模拟运行确认无误后再移除--dryrun执行。4.3 CloudWatch 日志与指标查询运维离不开监控。CloudWatch 的日志和指标查询通过 CLI 进行可以轻松集成到自动化告警或健康检查脚本中。查看 CloudWatch 日志组和流# 列出日志组 aws logs describe-log-groups # 列出特定日志组中的日志流 aws logs describe-log-streams --log-group-name /var/log/messages获取日志事件这是排查线上问题的关键。你可以获取特定时间范围内、特定日志流的最新日志。aws logs get-log-events \ --log-group-name /aws/lambda/my-function \ --log-stream-name 2024/07/10/[$LATEST]abc123def \ --start-time 1720600000000 \ --end-time 1720610000000 \ --limit 50这里的--start-time和--end-time参数需要的是 Unix 时间戳毫秒。一个实用技巧是如果你只是想看最新的日志可以省略时间参数或者使用--start-from-head从头开始读取。获取 CloudWatch 指标统计数据假设你想查看过去一小时内某个 EC2 实例的 CPU 平均利用率。aws cloudwatch get-metric-statistics \ --namespace AWS/EC2 \ --metric-name CPUUtilization \ --dimensions NameInstanceId,Valuei-1234567890abcdef0 \ --start-time 2024-07-10T00:00:00Z \ --end-time 2024-07-10T01:00:00Z \ --period 300 \ --statistics Average \ --output json这个命令的参数需要理解其含义--namespace和--metric-name指定了指标维度--dimensions是筛选条件这里是具体实例--period是统计粒度单位秒300秒即5分钟--statistics指定统计方法平均值、最大值、最小值等。通过组合这些参数你可以灵活地拉取任何需要的监控数据。5. 高级技巧与脚本化实战当你熟悉了基础命令后将这些命令组合起来形成脚本才能真正释放 CLI 的威力。5.1 使用 JMESPath 进行高级查询--query参数是 CLI 输出的“过滤器”。掌握 JMESPath 能让你精准提取所需数据。例如从describe-instances的复杂输出中快速找出所有正在运行running的实例 ID 和其标签Name的值aws ec2 describe-instances \ --query Reservations[*].Instances[?State.Namerunning].[InstanceId, Tags[?KeyName].Value | [0]] \ --output text这个查询做了几件事1) 筛选实例状态为running2) 为每个实例创建一个包含两个元素的列表InstanceId和Name标签的值3)| [0]是将标签值列表取出第一个元素因为一个实例只有一个Name标签。--output text则让结果以纯文本分行显示非常适合后续用xargs等工具处理。5.2 结合 Shell 脚本实现自动化一个常见的需求每天下午6点自动停止所有开发环境的 EC2 实例以节省成本。你可以写一个简单的 Shell 脚本#!/bin/bash # 脚本名stop-dev-instances.sh PROFILEdev REGIONus-east-1 # 1. 获取所有运行中实例的ID INSTANCE_IDS$(aws ec2 describe-instances \ --profile $PROFILE \ --region $REGION \ --query Reservations[*].Instances[?State.Namerunning].InstanceId \ --output text) # 2. 判断是否为空 if [ -z $INSTANCE_IDS ]; then echo No running instances found in $PROFILE account. exit 0 fi # 3. 停止这些实例 echo Stopping instances: $INSTANCE_IDS aws ec2 stop-instances \ --profile $PROFILE \ --region $REGION \ --instance-ids $INSTANCE_IDS # 4. 等待所有实例停止 echo Waiting for instances to stop... aws ec2 wait instance-stopped \ --profile $PROFILE \ --region $REGION \ --instance-ids $INSTANCE_IDS echo All specified instances have been stopped.然后使用 Linux 的cron或 macOS 的launchd将这个脚本设置为定时任务。这就是一个完整的、可用的自动化运维脚本雏形。5.3 利用--dry-run和--generate-cli-skeleton对于具有破坏性或复杂性的操作有两个参数能救命--dry-run 模拟执行命令检查你是否拥有执行该操作所需的权限而不会真正创建或修改任何资源。在运行terminate-instances、delete-bucket等命令前先用它验证一下。aws ec2 terminate-instances --instance-ids i-1234567890abcdef0 --dry-run如果权限不足你会收到一个UnauthorizedOperation错误如果权限足够则会提示DryRunOperation告诉你模拟成功可以执行。--generate-cli-skeleton和--cli-input-json 对于参数极其复杂的命令如run-instances你可以先让 CLI 生成一个包含所有可能参数的 JSON 模板文件然后在文件中编辑最后用--cli-input-json指定该文件来执行。这保证了参数结构的正确性也便于版本管理。# 生成模板 aws ec2 run-instances --generate-cli-skeleton launch-config.json # 编辑 launch-config.json 文件 # 使用模板启动实例 aws ec2 run-instances --cli-input-json file://launch-config.json6. 故障排查与日常维护心得即使配置正确在使用 CLI 过程中也难免会遇到问题。以下是我总结的几个常见故障点及排查思路。问题一命令执行报错 “An error occurred (AccessDenied) when calling the XXXX operation”根因 当前使用的 IAM 用户/角色没有执行该操作所需的权限。排查确认当前使用的 Profileaws sts get-caller-identity。检查该 IAM 实体附加的策略。可以尝试在 IAM 控制台进行策略模拟或使用 CLI 的--dry-run参数。确保没有因权限边界、服务控制策略SCP或资源策略如 S3 Bucket Policy导致拒绝访问。问题二命令执行缓慢或超时根因 网络问题、CLI 版本过旧、或者返回数据量过大。排查检查网络连接和代理设置如果使用了代理。CLI 默认使用系统代理你也可以通过HTTP_PROXY/HTTPS_PROXY环境变量配置。升级到最新版 AWS CLI v2。对于返回大量数据的命令如不加过滤的describe-instances使用--query限制返回字段或使用--max-items、--page-size进行分页。问题三配置文件冲突或凭证失效根因 存在多个凭证源环境变量、配置文件、EC2 元数据等优先级混乱或者 Access Key 已轮换/失效。排查AWS CLI 的凭证查找顺序是1) 命令行参数--aws-access-key-id2) 环境变量 (AWS_ACCESS_KEY_ID)3) CLI 配置文件~/.aws/credentials4) IAM 角色适用于 EC2 等。用aws configure list可以查看当前生效的配置来源和值。如果使用固定密钥检查密钥是否在 IAM 控制台被禁用或删除。如果使用 SSO运行aws sso login --profile profile-name重新登录刷新令牌。日常维护建议定期轮换 Access Key 即使不是强制要求也应定期如每90天在 IAM 控制台生成新的密钥对并更新本地配置文件。旧密钥禁用后保留几天再删除以防有未更新的脚本或应用还在使用。善用aws help 任何命令后加上help都能看到最权威、最详细的文档包括所有参数、子命令和示例。例如aws s3 help或aws ec2 run-instances help。启用 CLI 的自动补全 按照官方文档为你的 Shellbash, zsh启用命令和参数补全能极大提升输入效率和准确性避免因拼写错误导致的命令失败。
