1. 项目概述为什么一个老运维坚持手写 AWS CLI 实战笔记我第一次在客户现场用 AWS CLI 救火是凌晨三点。当时一个生产环境的 S3 存储桶被误删控制台操作慢、界面卡顿而客户要求“五分钟内恢复”。我打开终端敲下三行命令aws s3api list-object-versions --bucket xxx --query Versions[?starts_with(Key,logs/2024-03-15)] --output json | jq -r .[] | .Key | xargs -I {} aws s3api delete-object --bucket xxx --key {} --version-id {}再加一行aws s3 sync s3://backup-bucket/logs/2024-03-15 ./recovered/—— 2分47秒日志全量回滚完成。客户盯着屏幕没说话只默默给我续了一杯咖啡。这件事让我彻底明白AWS CLI 不是“另一个工具”而是你和云之间最短、最硬、最可控的那根线。它不讲 UI 美学不等页面渲染不依赖鼠标悬停提示它只认参数、权限、网络和你的判断力。今天这篇笔记不是照搬官方文档的翻译稿而是我过去六年在金融、电商、SaaS 三类客户环境里亲手踩过坑、调过参、写过脚本、修过故障后浓缩下来的实战手册。它不教你怎么点开 EC2 控制台而是告诉你当控制台打不开时怎么用aws ec2 describe-instances --filters Nametag:Env,Valuesprod --query Reservations[*].Instances[?State.Namerunning].[InstanceId,Tags[?KeyName].Value|[0]] --output table一眼锁定所有生产环境运行中的实例及其命名标签它不罗列所有 200 服务命令而是聚焦 EC2、S3、Lambda 这三个你每天必碰的核心服务把每个常用命令背后的“为什么这么写”“什么场景必须加--query”“--output text和--output table在自动化里怎么选”掰开揉碎讲透。关键词就藏在这段话里AWS CLI 实战、EC2 管理、S3 同步、Lambda 调用、IAM 权限配置、CLI 脚本自动化、jq 解析、CI/CD 集成、多账户切换、调试排错。如果你是刚考完 Cloud Practitioner 的新人这篇笔记会帮你把考纲里的“理解 CLI 概念”变成肌肉记忆如果你是带团队的 DevOps 工程师文末的“生产级脚本模板”和“CI/CD 安全注入方案”能直接抄进你们的 GitLab 或 Jenkins 流水线。它不承诺“零基础速成”但保证每一步命令你都能在自己电脑上敲出来、看到结果、理解原理——因为所有示例都来自我真实工作目录里的.bash_history记录。2. 核心设计思路为什么放弃“一键安装包”坚持手动拆解每一步很多人装完 AWS CLI 就卡在第一步aws configure输完密钥一跑命令就报错Unable to locate credentials。问题往往不出在密钥本身而出在“安装路径”和“配置层级”的认知偏差上。我见过太多人用 Homebrew 装了 CLI却把~/.aws/credentials文件写在了 Docker 容器里也见过用 Windows MSI 安装后在 WSL 里执行aws --version显示版本但aws sts get-caller-identity却提示区域未配置——因为 Windows 和 WSL 的家目录%USERPROFILE%vs/home/username根本不是同一个地方。所以我的设计逻辑非常明确不教“怎么点下一步”而教“每一步背后操作系统和 CLI 的对话机制是什么”。先说安装。AWS 官方推荐 v2这没错但 v2 的安装方式直接决定了你后续维护成本。Windows 用户如果图省事用 MSI 安装未来升级就得重新下载、双击、点“Next”——而企业环境里你可能要批量更新 50 台开发机。所以我坚持推荐Windows Subsystem for Linux (WSL) curl 安装法curl https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip -o awscliv2.zip unzip awscliv2.zip sudo ./aws/install。为什么因为这条命令可以无脑复制进 Ansible Playbook 或 PowerShell 脚本一次下发全网生效。Mac 用户同理Homebrew 是首选但必须强调brew install awscli和brew install aws-tk的本质区别前者是 CLI 本体后者是配套的凭证管理工具如aws-sso-util新手常混淆。Linux 环境最典型的是 Amazon Linux 预装旧版 CLIyum remove awscli看似简单实则危险——它会连带卸载python3-pip导致后续pip3 install boto3失败。我的方案是sudo yum remove -y awscli sudo rm -rf /usr/bin/aws* curl ...先暴力清理再干净安装。再看配置。官方文档说“运行aws configure”但没说清楚这个命令到底改了哪两个文件.aws/credentials和.aws/config的分工是什么为什么aws configure set region us-east-1写进 config而aws_access_key_id却必须写进 credentials答案在于 AWS 的凭证链Credential Chain机制CLI 启动时会按固定顺序检查 5 个来源环境变量 ~/.aws/credentials~/.aws/config IAM Roles for EC2 Web Identity Token。aws configure默认只操作前两个文件而region这种非敏感配置允许放在 config 里但密钥对必须严格隔离在 credentials 中——这是安全基线。所以我从不教“直接编辑文件”而是教aws configure set profile.dev.region ap-southeast-1这种带 profile 前缀的写法因为它强制你建立“配置即代码”的思维每个环境dev/staging/prod对应独立 profile所有参数可版本化管理。最后是命令设计。为什么 EC2 的describe-instances默认返回巨长 JSON而 S3 的ls却是简洁表格因为 S3 CLI 是 AWS 封装的高级命令aws s3它内部做了大量格式化处理而 EC2 CLI 是直通 API 的底层命令aws ec2返回原始响应。新手常因此困惑“为什么aws s3 ls能直接看aws ec2 describe-instances却要| jq”——这不是 CLI 的缺陷而是 AWS 的架构哲学S3 面向对象存储场景需要人性化交互EC2 面向基础设施编排需要机器可解析输出。所以我的笔记里所有 EC2 示例都默认带上--query和--output组合比如aws ec2 describe-instances --query Reservations[*].Instances[?State.Namerunning].[InstanceId,InstanceType,LaunchTime] --output table让你从第一天就习惯“结构化查询”而不是靠肉眼在千行 JSON 里找 ID。提示永远不要在生产环境用aws configure交互式输入密钥。正确姿势是echo [prod]\naws_access_key_id AKIA...\naws_secret_access_key ... ~/.aws/credentials配合chmod 600 ~/.aws/credentials。交互式输入会把密钥明文留在 shell history 里history | grep aws就能挖出来。3. 核心细节解析与实操要点从安装到配置的 12 个关键动作3.1 安装验证三步确认法绕过所有“看似成功”的假象安装完成≠可用。我见过太多人aws --version返回aws-cli/2.13.15就以为万事大吉结果一执行aws s3 ls就报错NoCredentialsError。真正的验证必须分三步走第一步二进制路径校验在终端执行which aws确认返回路径。Windows 用户注意WSL 下应为/usr/local/bin/aws而非 Windows 的C:\Program Files\Amazon\AWSCLIV2\aws.exeMac 用户若用 Homebrew应为/opt/homebrew/bin/awsM1/M2或/usr/local/bin/awsIntel。路径错误意味着你可能同时装了多个版本CLI 会调用第一个找到的造成行为不一致。第二步Python 环境探查AWS CLI v2 是 Python 应用其依赖库版本直接影响功能。执行aws --version后追加python3 -c import boto3; print(boto3.__version__)。如果 boto3 版本低于 1.28.0对应 CLI v2.13.x某些新 API如ec2 describe-instances的InstanceLifecycle字段将无法解析。此时需升级pip3 install --upgrade boto3。注意不要用sudo pip3而应pip3 install --user --upgrade boto3避免污染系统 Python。第三步最小权限测试别急着aws configure先用临时凭证测试基础链路。执行aws sts get-caller-identity --no-verify-ssl 2/dev/null || echo Failed。--no-verify-ssl参数很关键——它绕过 SSL 证书校验专治企业内网代理环境下的SSLError: certificate verify failed。如果这步失败说明网络或 DNS 有问题如果成功证明 CLI 二进制、Python 环境、基础网络全部就绪此时再配置正式凭证才不会被干扰因素误导。3.2 凭证配置IAM 用户 vs IAM Identity Center 的 5 个实操差异点凭证配置是最大雷区。我整理了两种主流方式的硬核差异全是血泪教训对比项IAM 用户凭证IAM Identity Center 凭证凭证有效期永久有效除非手动轮换Session Token 默认 1 小时过期最长 12 小时存储位置~/.aws/credentials纯文本~/.aws/credentials含aws_session_token~/.aws/sso/cache/JWT 缓存刷新机制手动创建新 Access Key替换文件aws sso login --profile my-prod自动刷新无需接触密钥权限粒度直接绑定 IAM Policy通过 Permission Set 关联 IAM RolePolicy 由管理员集中管控审计追踪CloudTrail 记录sts:GetSessionTokenCloudTrail 记录sso:CreateTokensts:AssumeRoleWithWebIdentity实操中我坚持新项目一律用 IAM Identity Center。原因很简单某次客户审计发现他们 300 开发者的 IAM 用户密钥平均使用时长 2.3 年其中 12% 密钥从未轮换。而 Identity Center 的 Session Token 强制过期天然符合 SOC2 合规要求。但切换时有 3 个坑必须填平Profile 命名陷阱aws configure sso创建的 profile 名默认是default但aws sso login会覆盖它。正确做法是aws configure sso --profile prod-sso然后aws sso login --profile prod-sso。这样prod-ssoprofile 永远指向 SSO 凭证default可留给本地测试。缓存失效处理当aws sso login报错The SSO session has expired别急着重登。先执行rm -rf ~/.aws/sso/cache/*清空 JWT 缓存再aws sso login --profile prod-sso。否则旧 token 会持续干扰。跨账户角色假设Identity Center 默认只能访问本账户资源。若需操作其他账户如 Central Logging 账户管理员必须在目标账户创建 Trust Policy允许arn:aws:iam::IdentityCenterAccountID:role/AWSReservedSSO_*角色被假设。我在~/.aws/config中这样写[profile cross-account] sso_start_url https://your-company.awsapps.com/start sso_region us-east-1 sso_account_id 123456789012 sso_role_name AWSReservedSSO_AdministratorAccess_abc123 region us-west-23.3 配置文件深度解析.aws/config里那些被忽略的 7 行关键代码~/.aws/config文件常被当成“放 region 的地方”其实它是 CLI 的中枢神经。我拆解一份生产环境使用的 config 文件标注每一行的真实作用# 第1行全局默认设置所有 profile 继承 [default] region ap-southeast-1 output json cli_pager cli_history enabled # 第2行指定此 profile 使用 SSO 登录核心 [profile dev-sso] sso_start_url https://mycompany.awsapps.com/start sso_region us-east-1 sso_account_id 111111111111 sso_role_name AWSReservedSSO_DeveloperAccess_abc123 region ap-southeast-1 output table # 注意此处覆盖 default 的 json 输出 # 第3行为 Lambda 部署专用 profile禁用 pager 避免阻塞流水线 [profile lambda-deploy] role_arn arn:aws:iam::222222222222:role/CICD-Lambda-Deployer source_profile dev-sso region us-west-2 cli_pager # 关键CI/CD 中必须设为空字符串否则 less 会挂起进程 cli_timestamp_format iso8601_ms # 精确到毫秒的时间戳便于日志追踪 # 第4行EC2 实例内使用的 profile无需密钥自动获取 IAM Role [profile ec2-instance] role_arn arn:aws:iam::333333333333:role/EC2-WebServer credential_source Ec2InstanceMetadata region us-east-1 # 第5行调试专用 profile开启详细日志 [profile debug] region us-east-1 output json cli_pager logging true # 此行启用 ~/.aws/cli/ 目录下的 debug 日志重点解释三处易错配置cli_pager 很多教程说“设为空字符串禁用分页”但没说清后果。在 CI/CD 流水线中如果未禁用aws s3 ls输出超过一屏时CLI 会启动less等待用户按键导致流水线永久挂起。必须显式设为空。credential_source Ec2InstanceMetadata这是 EC2 实例内免密访问的关键。它告诉 CLI“别找文件里的密钥去http://169.254.169.254/latest/meta-data/iam/security-credentials/拉临时凭证”。但前提是 EC2 启动时绑定了 IAM Role且 Role Policy 允许s3:GetObject等操作。logging true开启后CLI 会在~/.aws/cli/下生成debug.log记录每次 HTTP 请求的完整 URL、Headers、Body 和响应。当遇到InvalidSignatureException时这是唯一能定位签名错误根源的日志比如时钟不同步导致签名失效。3.4 输出格式实战JSON/Table/Text 三剑客的取舍逻辑--output参数不是个人喜好问题而是工程决策。我用一张表说明何时该用哪种格式场景推荐格式原因反例人工排查如查看某个 EC2 实例详情table列对齐字段名清晰一眼定位State、InstanceTypejson输出 200 行嵌套肉眼难扫Shell 脚本解析如提取所有 running 实例 IDtext纯文本无符号awk {print $2}直接取第二列table输出含表头分隔线grep -v ^-才能过滤CI/CD 日志归档如保存部署前状态快照json结构化、可追溯、兼容所有解析工具jq/pythontext无字段标识后续无法做字段级分析监控告警如检查 S3 存储桶数量是否超阈值textaws s3 ls | wc -l直接计数无额外字符干扰table输出含PRE前缀和空格wc -l会多算表头行实操案例统计所有区域中running状态的 EC2 实例总数。很多人写# 错误table 格式含表头wc -l 会多算 1 行 aws ec2 describe-instances --filters Nameinstance-state-name,Valuesrunning --output table | wc -l # 正确text 格式纯净且用 --query 精准提取 aws ec2 describe-instances --filters Nameinstance-state-name,Valuesrunning --query length(Reservations[].Instances[]) --output text这里--query length(...)是关键——它让 CLI 在服务端就计算好数量避免把上千实例的完整 JSON 拉到本地再解析既快又省流量。注意--output text仅适用于--query指定单个值的场景。若--query返回数组如--query Reservations[].Instances[].InstanceIdtext输出会用制表符分隔此时用--output jsonjq -r .[]更可靠。4. 实操过程与核心环节实现EC2/S3/Lambda 三大服务的 18 个高频命令详解4.1 EC2 管理从启动到销毁的 7 个不可跳过的命令链EC2 是 AWS 最复杂的服务之一CLI 操作必须形成闭环。我以“启动一台带标签的 Web 服务器”为例展示完整链路Step 1精准选择 AMI避免硬编码别再用--image-id ami-0bd55ebedabddc3c0这种静态 ID。生产环境必须动态查# 查找最新 Amazon Linux 2023 AMI按名称模糊匹配 aws ec2 describe-images \ --owners amazon \ --filters Namename,Valuesal2023-ami-2023.*-x86_64 Namestate,Valuesavailable \ --query sort_by(Images, CreationDate)[-1].[ImageId,Name,CreationDate] \ --output table # 输出示例 # ----------------------------------------------- # | DescribeImages | # ------------------------------------------ # | ami-0a1b2c3d4e5f67890 | al2023-ami-2023.2.20231212-x86_64 | 2023-12-12T00:00:00.000Z | # ------------------------------------------sort_by(...)[-1]取最新创建的 AMICreationDate是 jq 的 sort key 语法。这样脚本永远用最新安全补丁的 AMI。Step 2启动实例并立即打标签run-instances命令支持--tag-specifications避免启动后二次调用create-tagsaws ec2 run-instances \ --image-id ami-0a1b2c3d4e5f67890 \ --count 1 \ --instance-type t3.micro \ --key-name my-key-pair \ --security-group-ids sg-0abcdef1234567890 \ --subnet-id subnet-0123456789abcdef0 \ --tag-specifications \ ResourceTypeinstance,Tags[{KeyName,Valueweb-server-prod},{KeyEnv,Valueprod},{KeyTeam,Valuebackend}] \ ResourceTypevolume,Tags[{KeyName,Valueweb-server-prod-root},{KeyBackup,Valuedaily}] \ --query Instances[0].InstanceId \ --output text注意--tag-specifications支持为实例instance和根卷volume同时打标--query直接提取 InstanceId省去后续describe-instances查询。Step 3等待实例运行并获取公网 IPwait instance-running只是等待状态不返回 IP。必须组合describe-instancesINSTANCE_ID$(aws ec2 run-instances ... --query Instances[0].InstanceId --output text) aws ec2 wait instance-running --instance-ids $INSTANCE_ID # 获取公网 IP若分配了 EIP则 PublicIpAddress 为空需查 NetworkInterface aws ec2 describe-instances --instance-ids $INSTANCE_ID \ --query Reservations[0].Instances[0].{PublicIP:PublicIpAddress,PrivateIP:PrivateIpAddress,State:State.Name} \ --output tableStep 4连接实例前的安全检查别急着ssh先确认安全组入站规则# 查看实例绑定的安全组的入站规则只显示 SSH 和 HTTP aws ec2 describe-security-groups \ --group-ids sg-0abcdef1234567890 \ --query SecurityGroups[0].IpPermissions[?contains(IpProtocol, tcp) contains(FromPort, 22) || contains(FromPort, 80) || contains(FromPort, 443) ] \ --output table如果FromPort是-1表示所有端口开放这是严重安全隐患必须立即修正。Step 5优雅停止/启动非强制终止stop-instances和start-instances是软操作保留实例状态。但要注意stop-instances后EBS 卷仍保留但实例的 Public IP 会释放除非是 EIP。start-instances会分配新 Public IP若需固定 IP必须提前关联 EIP# 分配 EIP 并关联到实例 ALLOCATION_ID$(aws ec2 allocate-address --domain vpc --query AllocationId --output text) aws ec2 associate-address --allocation-id $ALLOCATION_ID --instance-id $INSTANCE_IDStep 6终止实例前的数据保护terminate-instances不可逆。生产环境必须加防护# 检查实例是否有 EBS 卷标记为 DeleteOnTerminationtrue aws ec2 describe-instances --instance-ids $INSTANCE_ID \ --query Reservations[0].Instances[0].BlockDeviceMappings[?Ebs.DeleteOnTerminationtrue].[DeviceName,Ebs.VolumeId] \ --output table # 若有先修改为 false确保数据卷不被删除 aws ec2 modify-instance-attribute \ --instance-id $INSTANCE_ID \ --block-device-mappings [{DeviceName:/dev/xvda,Ebs:{DeleteOnTermination:false}}]Step 7批量操作的黄金法则对 10 实例操作绝不用循环。用--filters--query一次性处理# 停止所有 tag:Envstaging 且 Staterunning 的实例 aws ec2 stop-instances \ --instance-ids $(aws ec2 describe-instances \ --filters Nametag:Env,Valuesstaging Nameinstance-state-name,Valuesrunning \ --query Reservations[*].Instances[*].InstanceId \ --output text) # 为所有停止的实例添加 StoppedByCLI 标签 aws ec2 create-tags \ --resources $(aws ec2 describe-instances \ --filters Nameinstance-state-name,Valuesstopped \ --query Reservations[*].Instances[*].InstanceId \ --output text) \ --tags KeyStoppedByCLI,Value$(date %Y-%m-%d)4.2 S3 管理同步、版本控制与生命周期的 6 个关键命令S3 CLI 的aws s3命令是封装层比aws s3api更友好但必须理解其行为边界Command 1aws s3 mb的隐藏限制aws s3 mb s3://my-bucket要求 bucket name 全局唯一且不能含下划线_。但更隐蔽的限制是bucket name 不能是纯数字也不能以xn--开头Punycode 编码。生产环境必须预检BUCKET_NAMEmy-app-logs-$(date %Y%m%d)-${RANDOM} # 检查是否合法正则小写字母、数字、连字符且不以连字符开头/结尾 if [[ ! $BUCKET_NAME ~ ^[a-z0-9][a-z0-9\-]*[a-z0-9]$ ]]; then echo Invalid bucket name: $BUCKET_NAME exit 1 fi aws s3 mb s3://$BUCKET_NAME --region us-west-2Command 2aws s3 sync的四大陷阱sync是最常用也最危险的命令--delete参数同步时删除目标中源不存在的文件。生产环境严禁无条件使用。正确姿势是先--dryrunaws s3 sync ./local/ s3://my-bucket/ --dryrun --exclude *.tmp | head -20时间精度S3 对象的 LastModified 时间精确到秒而本地文件系统如 ext4精确到纳秒。sync默认比较时间戳可能导致误判。解决方案是加--exact-timestampsCLI v2.11或--size-only。大文件分块sync会自动分块上传但--max-concurrent-requests默认 10内网带宽不足时会拖慢。建议根据网络调整aws s3 sync ... --max-concurrent-requests 5。加密--sse AES256启用服务端加密但--sse-c客户主密钥需额外提供密钥生产环境慎用。Command 3版本控制的强制启用S3 版本控制是数据安全基石但 CLI 不提供一键开启。必须用s3api# 启用版本控制幂等操作多次执行无副作用 aws s3api put-bucket-versioning \ --bucket my-bucket \ --versioning-configuration StatusEnabled # 验证是否启用 aws s3api get-bucket-versioning --bucket my-bucket --query Status --output text # 输出 Enabled 即成功Command 4aws s3 ls的深度解析ls默认只显示最近版本。要查所有版本包括删除标记# 列出所有对象版本含 DeleteMarkers aws s3api list-object-versions \ --bucket my-bucket \ --query Versions[?not_null(LastModified)].[Key,VersionId,LastModified,IsLatest] \ --output table # 列出所有删除标记 aws s3api list-object-versions \ --bucket my-bucket \ --query DeleteMarkers[?not_null(LastModified)].[Key,VersionId,LastModified] \ --output tableCommand 5生命周期策略的 CLI 部署策略必须是 JSON 格式CLI 不支持交互式编辑。生产环境用文件管理# 创建 lifecycle.json 文件 cat lifecycle.json EOF { Rules: [ { Expiration: { Days: 30 }, ID: DeleteOldLogs, Prefix: logs/, Status: Enabled, Transitions: [ { Days: 7, StorageClass: STANDARD_IA } ] } ] } EOF # 应用策略 aws s3api put-bucket-lifecycle-configuration \ --bucket my-bucket \ --lifecycle-configuration file://lifecycle.jsonCommand 6跨区域复制的权限配置aws s3 sync不能跨区域。跨区域必须用s3api copy-object或启用 S3 Replication。Replication 需要源/目标桶的特殊权限# 为目标桶添加 replication 权限源桶策略中引用此 ARN aws s3api put-bucket-policy \ --bucket my-bucket-us-west-2 \ --policy { Version: 2012-10-17, Statement: [ { Effect: Allow, Principal: {Service: s3.amazonaws.com}, Action: [s3:GetReplicationConfiguration, s3:ListBucket], Resource: [arn:aws:s3:::my-bucket-us-west-2, arn:aws:s3:::my-bucket-us-west-2/*] } ] }4.3 Lambda 管理从部署到调试的 5 个核心命令Lambda CLI 的关键是理解--zip-file和--code的区别Command 1部署函数的三种方式对比方式命令适用场景限制本地 ZIP--zip-file fileb://function.zip小函数50MB开发测试ZIP 必须在本地不能是 S3 URIS3 ZIP--code S3Bucketmy-bucket,S3Keyfunction.zip大函数50MBCI/CD 流水线S3 桶必须与 Lambda 同区域容器镜像--code ImageUri123456789012.dkr.ecr.us-east-1.amazonaws.com/my-function:latest复杂依赖如机器学习库需提前构建并推送 ECR生产环境我只用 S3 方式因为ZIP 文件可版本化S3 Object Versioning部署命令幂等相同 S3Key 不会重复触发更新可审计CloudTrail 记录PutFunctionCodeCommand 2环境变量的安全注入绝不在命令行硬编码--environment Variables{KEY1VALUE1}。正确姿势是# 从文件读取环境变量文件内容为 JSON cat env.json EOF { Variables: { DB_HOST: prod-db.cluster-abc123.us-east-1.rds.amazonaws.com, LOG_LEVEL: INFO } } EOF aws lambda update-function-configuration \ --function-name my-function \ --environment file://env.jsonCommand 3权限模型的 CLI 配置Lambda 执行角色Execution Role必须通过add-permission显式授权# 为 Lambda 添加调用 SQS 的权限这是常见需求 aws lambda add-permission \ --function-name my-function \ --statement-id sqs-invoke \ --action lambda:InvokeFunction \ --principal sqs.amazonaws.com \ --source-arn arn:aws:sqs:us-east-1:123456789012:my-queue \ --source-account 123456789012Command 4调试函数的实时日志流aws lambda invoke默认不返回日志。要实时看 CloudWatch Logs# 调用函数并获取日志LogResult 字段是 base64 编码 LOG_RESULT$(aws lambda invoke \ --function-name my-function \ --payload {key: value} \ --log-type Tail \ --query LogResult \ --output text) # 解码日志并实时输出 echo $LOG_RESULT | base64 -d | tail -n 2 # tail -n 2 去掉第一行时间戳Command 5别名与版本的灰度发布用别名实现零停机发布# 发布新版本 VERSION$(aws lambda publish-version \ --function-name my-function \ --description v2.1.0 - Fix memory leak \ --query Version \ --output text) # 将别名 prod 指向新版本权重 100% aws lambda update-alias \ --function-name my-function \ --name prod \ --function-version $VERSION # 灰度发布将 10% 流量切到新版本 aws lambda update-alias \ --function-name my-function \ --name prod \ --routing-config AdditionalVersionWeights{$VERSION:0.1}5. 常见问题与排查技巧实录21 个真实故障场景及解决方法5.1 认证