如何高效地配置和管理多个 AWS CLI 配置文件
了解如何使用 AWS CLI 命名配置文件来高效管理多个 AWS 账户和环境。本指南提供了有关配置、切换以及保护不同 AWS 凭证和设置集的分步说明。通过掌握配置文件管理,优化您的云工作流程,以提高生产力和安全性。
如何高效配置和管理多个 AWS CLI 配置文件
AWS CLI 配置文件可让您的账户、角色、区域和输出设置保持分离。如果您在同一台笔记本电脑上管理开发、预发布和生产环境,配置文件可帮助您避免对错误的 AWS 账户运行命令。
目标很简单:明确指定目标账户,尽可能减少长期凭证,并在执行破坏性命令前进行快速检查。
设置 AWS CLI 配置文件
AWS CLI 将配置文件设置存储在两个共享文件中:
~/.aws/credentials用于访问密钥和会话凭证。~/.aws/config用于区域、输出格式、角色设置和其他 CLI 选项。
在 Windows 上,这些文件位于 %USERPROFILE%\.aws\ 下。
默认配置文件
当您运行 aws configure 而不带 --profile 时,它会为 [default] 写入设置。当您未指定其他配置文件且没有相关环境变量覆盖时,CLI 会使用此配置文件。
# ~/.aws/credentials 中默认配置文件的示例
[default]
aws_access_key_id = YOUR_DEFAULT_ACCESS_KEY
aws_secret_access_key = YOUR_DEFAULT_SECRET_KEY
# ~/.aws/config 中默认配置文件的示例
[default]
region = us-east-1
output = json
创建命名配置文件
您可以使用 aws configure --profile 创建命名配置文件:
aws configure --profile dev
aws configure --profile prod
您也可以直接编辑文件。在 ~/.aws/credentials 中使用纯配置文件名称:
~/.aws/credentials:
[default]
aws_access_key_id = YOUR_DEFAULT_ACCESS_KEY
aws_secret_access_key = YOUR_DEFAULT_SECRET_KEY
[prod]
aws_access_key_id = YOUR_PROD_ACCESS_KEY
aws_secret_access_key = YOUR_PROD_SECRET_KEY
[dev]
aws_access_key_id = YOUR_DEV_ACCESS_KEY
aws_secret_access_key = YOUR_DEV_SECRET_KEY
在 ~/.aws/config 中,命名配置文件使用 profile 前缀:
~/.aws/config:
[default]
region = us-east-1
output = json
[profile prod]
region = us-west-2
output = text
[profile dev]
region = eu-central-1
output = json
重要细节:
- 在
~/.aws/config中定义配置文件时,必须在配置文件名称前加上profile前缀(例如[profile prod])。这与~/.aws/credentials不同,后者仅使用配置文件名称(例如[prod])。 [default]配置文件不会自动作为命名配置文件的父级。如果prod需要区域,请在[profile prod]下设置region或以其他方式提供。
在配置文件之间切换
设置好命名配置文件后,您可以通过在 AWS CLI 命令中指定 --profile 选项来使用它们。
示例: 列出生产账户中的 S3 存储桶:
aws s3 ls --profile prod
示例: 描述开发账户中的 EC2 实例:
aws ec2 describe-instances --profile dev
在运行风险命令之前,请验证您的身份:
aws sts get-caller-identity --profile prod
这将返回 CLI 正在使用的凭证的账户 ID 和 ARN。
为环境设置默认配置文件
不断输入 --profile 可能很繁琐。您可以为当前 shell 会话设置 AWS_PROFILE。
Linux/macOS:
export AWS_PROFILE=prod
# 现在,命令将默认使用 'prod' 配置文件
aws s3 ls
aws ec2 describe-instances
要取消设置:
unset AWS_PROFILE
Windows 命令提示符:
set AWS_PROFILE=prod
# 现在,命令将默认使用 'prod' 配置文件
aws s3 ls
要取消设置:
set AWS_PROFILE=
Windows PowerShell:
$env:AWS_PROFILE = "prod"
# 现在,命令将默认使用 'prod' 配置文件
aws s3 ls
要取消设置:
Remove-Item Env:\AWS_PROFILE
命令行选项的优先级高于环境变量。如果设置了 AWS_PROFILE=dev,但您运行 aws s3 ls --profile prod,则命令使用 prod。
使用配置文件管理多个 AWS 账户
配置文件对于以下情况很有用:
- 开发与生产: 将开发和生产环境分开以确保安全。
- 不同团队/项目: 隔离不同团队或项目的资源和权限。
- 跨账户访问: 如果您是需要管理多个账户中资源的管理员或开发人员。
最佳实践:使用 IAM 角色
避免为每个账户存储长期访问密钥。一种常见模式是保留一个源配置文件或 SSO 配置文件,然后承担目标账户的角色。
对于角色承担,配置如下配置文件:
# ~/.aws/config
[profile dev-role]
role_arn = arn:aws:iam::ACCOUNT_ID:role/ROLE_NAME
source_profile = default
region = us-east-1
output = json
当您使用 --profile dev-role 运行命令时,CLI 使用 default 配置文件调用 AWS STS,承担角色,并使用临时凭证执行命令。
如果您的组织使用 IAM Identity Center,您的配置文件可能使用 SSO 设置而不是访问密钥:
[profile sandbox]
sso_start_url = https://example.awsapps.com/start
sso_region = us-east-1
sso_account_id = 123456789012
sso_role_name = DeveloperAccess
region = us-east-1
output = json
然后使用以下命令进行身份验证:
aws sso login --profile sandbox
高级配置选项
除了凭证和区域,配置文件还可以指定其他 AWS CLI 设置:
output:json、text、tableregion:例如us-east-1s3.max_concurrent_requests:S3 操作的并行请求数。s3.max_queue_size:S3 分段上传的队列大小。cli_binary_format:AWS CLI v2 中二进制参数的解释方式。
示例:为特定配置文件配置 S3 设置
使用 aws configure set 避免缩进错误:
aws configure set s3.max_concurrent_requests 20 --profile s3-optimized
aws configure set s3.max_queue_size 10000 --profile s3-optimized
这会将 S3 设置写入 ~/.aws/config 中配置文件下:
# ~/.aws/config
[profile s3-optimized]
region = us-east-1
output = json
s3 =
max_concurrent_requests = 20
max_queue_size = 10000
提示和最佳实践
- 使用描述性配置文件名称: 使配置文件名称清晰并指示其代表的账户或环境(例如
prod-admin、dev-web、sandbox-research)。 - 保护您的凭证: 切勿将
~/.aws/credentials文件提交到版本控制。尽可能使用 IAM 角色进行跨账户访问,以避免存储长期访问密钥。 - 定期审查访问密钥: 如果必须使用访问密钥,请定期轮换并禁用旧密钥。
- 利用环境变量: 使用
AWS_PROFILE进行临时切换,或用于需要定位特定账户的 CI/CD 管道。 - 注意凭证环境变量:
AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY和AWS_SESSION_TOKEN可以覆盖配置文件中的凭证。如果 CLI 似乎使用了错误的身份,请清除它们。 - 根据影响范围命名配置文件: 像
prod-readonly、prod-admin和sandbox-dev这样的名称比模糊的名称如main或test更安全。
实用要点
为您经常使用的每个账户和角色使用配置文件,并在更改生产资源之前检查 aws sts get-caller-identity。优先使用 SSO 或基于角色的配置文件,而不是长期访问密钥,并在命令似乎针对错误账户时注意环境变量。