1. 这不是“又一篇CLI教程”而是一份 AWS CLI 实战生存指南AWS CLIAmazon Web Services Command Line Interface绝不是个可有可无的玩具命令行工具它是云基础设施操作的“物理接口”——当你在控制台点下“启动实例”按钮时背后调用的正是 CLI 封装好的 API当你在 Terraform 中定义一个 S3 存储桶时底层资源创建、策略绑定、跨区域复制配置全都可以用几行 CLI 命令完成验证与调试。我从 2014 年开始在金融客户现场做云迁移亲手用 CLI 搭建过 37 个生产级 VPC 网络处理过凌晨三点因 IAM 权限链断裂导致整个 CI/CD 流水线卡死的故障也经历过因--dry-run忘加参数误删了客户核心日志桶的惊魂一刻。这篇内容不讲“什么是 CLI”不堆砌aws s3 ls和aws ec2 describe-instances这类教科书式示例而是聚焦真实工作流中你一定会踩的坑、必须掌握的权限逻辑、无法绕开的配置陷阱以及那些 AWS 官方文档里轻描淡写、但实际决定项目成败的细节。它适合三类人刚考完 AWS Certified Cloud Practitioner 想把知识落地的新人每天和 CloudFormation 模板打交道、却总在aws cloudformation deploy报错时抓耳挠腮的中级工程师还有负责搭建企业级多账号组织架构、需要批量管理数百个账户 IAM 角色的云平台负责人。核心关键词是AWS CLI、IAM 角色链、配置文件分层、JSON 输出解析、命令执行上下文、凭证优先级机制。如果你只打算复制粘贴几个命令就走那这篇会显得冗长但如果你正被Unable to locate credentials卡住两小时或搞不清为什么--profile dev有时生效有时失效那你已经站在了真正理解 AWS CLI 的起点上。2. 为什么必须放弃“一键安装”思维CLI 的安装与初始化本质是权限信任链的建立2.1 安装方式选择pip vs MSI vs brew —— 不是技术偏好而是环境治理策略很多人看到官方文档推荐pip install awscli就立刻执行结果在 CentOS 7 的生产服务器上因为 Python 2.7 与 pip 版本冲突卡在ImportError: No module named urllib3一整天。这不是 CLI 的问题而是你跳过了最关键的环境适配判断。AWS CLI v2 是独立二进制包v1 才依赖 Python 环境。当前2024年所有新项目必须无条件使用 CLI v2理由非常硬核v1 已于 2023 年 7 月正式停止维护其底层使用的 botocore 库不再接收安全补丁更重要的是v2 原生支持 SSO 登录、FIPS 终端、ARM64 架构且命令执行速度平均快 40%实测 1000 行 JSON 输出解析耗时从 2.3s 降至 1.4s。所以安装决策树非常清晰Linux 服务器尤其是 RHEL/CentOS/Ubuntu LTS绝对不用 pip。直接下载.zip包解压到/usr/local/bin并设置软链接。原因在于系统级 Python 环境极其脆弱pip install可能污染全局 site-packages导致 Ansible 或其他运维工具异常而二进制包完全隔离升级只需替换文件符合企业级配置管理规范。macOS 开发机brew install awscli是最优解。Homebrew 会自动处理zshshell 配置、路径注入并在更新时校验签名。我试过手动下载 zip 包结果因 macOS Gatekeeper 对未签名二进制的拦截反复弹窗确认团队新人平均要花 12 分钟才能完成首次运行。Windows 企业桌面MSI 安装包是唯一合规选择。.msi文件支持静默安装msiexec /i awscliv2.msi /qn可集成进 SCCM 或 Intune 部署流程而choco install awscli虽然方便但 Chocolatey 默认启用远程脚本执行违反多数金融客户的安全基线要求。提示无论哪种安装方式安装后第一件事不是运行aws --version而是执行aws configure list。这个命令会立即暴露你的环境是否干净——如果输出中access_key显示cached或sso说明你机器上残留着旧版配置或 SSO 会话必须先清理否则后续所有命令都会在错误的认证上下文中执行。2.2 初始化 setup 的本质构建三层凭证信任模型aws configure这个命令被严重误解了。它根本不是“设置账号密码”而是在本地文件系统中为 AWS 的四层凭证查找机制Credential Provider Chain预埋一个基础锚点。AWS CLI 查找凭证的顺序是严格固定的环境变量 →~/.aws/credentials→~/.aws/config→ IAM 角色EC2 实例元数据→ Web Identity TokenEKS Service Account。aws configure只影响前两个文件但它决定了整个链条的起点是否可靠。我们来拆解一次真实的aws configure过程。假设你拿到的是一个 IAM 用户的 Access Key ID 和 Secret Access Key注意这仅适用于开发测试生产环境严禁使用长期密钥$ aws configure --profile prod-core AWS Access Key ID [None]: AKIAZ...XQ3A AWS Secret Access Key [None]: 9Kp...Vf8 Default region name [None]: us-east-1 Default output format [None]: json这里四个输入项每一项都对应一个关键设计Profile 名称--profile prod-core这不是随便起的昵称。它是一个命名空间隔离器。当你有prod-core、prod-analytics、staging-api三个 profile 时CLI 会将它们分别写入~/.aws/credentials的不同 section避免密钥混用。我见过最惨的事故是某工程师在~/.aws/credentials中手写了一个[default]section结果所有未指定--profile的命令都默认使用该密钥误删了生产数据库快照。Region 设置它不只决定 API 调用的终点更深层影响资源 ARN 的生成逻辑。例如aws s3 mb s3://my-bucket命令如果 region 设为us-east-1CLI 会向s3.amazonaws.com发请求若设为ap-northeast-1则发往s3.ap-northeast-1.amazonaws.com。更关键的是S3 的 bucket 名称全局唯一但us-east-1区域的 bucket 创建逻辑与其他区域不同早期兼容性设计region 配错会导致BucketAlreadyExists错误。Output Format设为json是唯一合理选择。text格式是为 shell 脚本cut -f2设计的但字段位置不稳定如aws ec2 describe-instances --query Reservations[*].Instances[*].[InstanceId,State.Name]在实例重启后 State 字段顺序可能变化table格式纯为人类阅读无法被jq解析。只有json是机器可读、可编程、可审计的黄金标准。注意aws configure从不存储明文密码。Secret Access Key 会被写入~/.aws/credentials但该文件权限被强制设为600仅属主可读写。如果你在 macOS 上用ls -l ~/.aws/credentials发现权限是644说明你曾用sudo aws configure执行过必须立即修复chmod 600 ~/.aws/credentials chown $USER ~/.aws/credentials。否则任何同服务器用户都能cat出你的密钥。2.3 配置文件的物理结构credentials与config的分工哲学这是 AWS CLI 最易混淆的设计。~/.aws/credentials和~/.aws/config是两个独立文件承担完全不同的职责~/.aws/credentials只存静态凭证。格式严格为 INI 风格每个[profile-name]下只能有aws_access_key_id和aws_secret_access_key两行。它不接受任何其他字段加了region us-west-2会被忽略。~/.aws/config只存运行时配置。格式也是 INI但必须以[profile profile-name]开头注意多了一个profile前缀。这里可以放region、output、role_arn、source_profile甚至credential_source Ec2InstanceMetadata。这种分离不是为了增加复杂度而是为了解决一个核心矛盾凭证who you are和上下文where you operate必须解耦。举个典型场景你有一个名为dev-admin的 IAM 用户它本身没有权限操作生产资源但可以通过AssumeRole切换到prod-audit角色。这时你的配置应该是~/.aws/credentials[dev-admin] aws_access_key_id AKIA... aws_secret_access_key 9Kp...~/.aws/config[profile dev-admin] region us-east-1 [profile prod-audit] role_arn arn:aws:iam::123456789012:role/ProdAuditRole source_profile dev-admin region us-west-2执行aws sts get-caller-identity --profile prod-audit时CLI 会先从credentials读取dev-admin的密钥再用这些密钥调用sts:AssumeRoleAPI 获取临时凭证最后用临时凭证调用目标服务。整个过程对用户透明但权限边界清晰——dev-admin用户永远无法直接访问prod-audit的资源只能通过角色切换这一条受控通道。实操心得我坚持一个原则——~/.aws/credentials文件中永远只保留一个[default]section且该 section 对应一个最低权限的“跳板用户”。所有具体业务 profile如prod-db-maintainer、staging-ci-runner都在config文件中定义通过source_profile default链接。这样做的好处是当跳板用户密钥轮换时只需改一处且credentials文件可安全提交到团队共享仓库不含敏感密钥而config文件中的role_arn是公开 ARN也不含密钥。3. 命令执行的核心逻辑不是“调用 API”而是构造可审计的执行上下文3.1 所有命令的隐式参数--profile、--region、--endpoint-url的优先级战争你以为aws s3 ls s3://my-bucket很简单其实 CLI 在后台默默做了至少 7 步决策。我们用aws --debug s3 ls s3://my-bucket 21 | head -20查看调试日志会发现第一行就是2024-04-15 10:23:42,123 - MainThread - awscli.clidriver - DEBUG - CLI version: aws-cli/2.13.15 Python/3.11.8 Darwin/23.3.0 source/x86_64 2024-04-15 10:23:42,124 - MainThread - awscli.clidriver - DEBUG - Arguments entered to CLI: [s3, ls, s3://my-bucket, --debug] 2024-04-15 10:23:42,125 - MainThread - botocore.hooks - DEBUG - Event building-command-table.s3: calling handler function add_s3_commands at 0x10a... 2024-04-15 10:23:42,126 - MainThread - botocore.hooks - DEBUG - Event building-command-table.s3: calling handler function add_s3api_commands at 0x10b... 2024-04-15 10:23:42,127 - MainThread - botocore.session - DEBUG - Loading variable profile from defaults.注意最后一行Loading variable profile from defaults—— 这表示 CLI 正在启动凭证查找链。而profile的确定遵循一个铁律命令行参数 环境变量 配置文件。具体优先级如下优先级来源示例覆盖范围1最高命令行--profileaws s3 ls --profile prod-core仅本次命令2环境变量AWS_PROFILEexport AWS_PROFILEprod-core当前 shell 会话及子进程3~/.aws/credentials中的[default][default]section 存在全局默认但可被更高优先级覆盖4~/.aws/config中的[default][profile default]section 存在仅提供配置不提供凭证这个优先级链解释了为什么很多工程师抱怨“--profile有时不生效”。真相往往是他们设置了export AWS_PROFILEstaging然后在另一个终端执行aws s3 ls --profile prod-core结果发现还是连到了 staging 环境。因为export设置的环境变量在另一个终端不存在或者更隐蔽的情况他们在 Jenkins Pipeline 中写了sh aws s3 cp ... --profile prod但 Jenkins agent 的环境变量里早已设置了AWS_PROFILEci于是--profile被无情忽略。提示诊断当前生效的 profile不要猜用命令验证aws configure list --profile $(aws configure list | grep profile | awk {print $2})。这条命令会先获取当前 profile 名再用该名重新查询确保你看到的是最终生效值。3.2--query与--filter的本质区别一个是 JSON 解析器一个是服务端过滤器这是 AWS CLI 最大的认知误区。几乎所有教程都说“--query用来筛选输出”但没说清它和--filter的根本差异。我们以 EC2 实例列表为例# 方式 A用 --filter服务端过滤 aws ec2 describe-instances \ --filters Nameinstance-state-name,Valuesrunning \ --query Reservations[*].Instances[*].[InstanceId,InstanceType,LaunchTime] \ --output table # 方式 B用 --query客户端过滤 aws ec2 describe-instances \ --query Reservations[*].Instances[?State.Namerunning].[InstanceId,InstanceType,LaunchTime] \ --output table表面看结果一样但性能和安全性天差地别--filters参数会作为 HTTP Query String 的一部分发送给 EC2 服务端。服务端在数据库层面执行过滤只返回符合条件的实例数据。如果你有 5000 个实例但只有 3 个是 running 状态那么网络传输的数据量只有 3 条记录的大小。--query参数则完全不同。CLI 会先向 EC2 发送一个不带 filter 的全量请求收到全部 5000 条实例的 JSON 响应可能高达 15MB然后在本地用JMESPath引擎逐条匹配State.Namerunning。这不仅慢实测 5000 实例全量拉取耗时 3.2s过滤后仅 0.1s更危险——如果响应体包含敏感字段如UserData的 base64 编码内容这些数据已完整传输到你的本地机器存在泄露风险。因此我的硬性规则是只要服务端支持--filters就绝不使用--query做状态过滤。--filters的语法是服务定义的每个服务不同S3 用--prefixRDS 用--db-instance-identifier但它的优势无可替代。--query的正确用途是对服务端已返回的、结构化的 JSON 数据进行投影projection、重排reorder、计算如length()统计数量、格式化如to_string(LaunchTime)转时间字符串。3.3--dry-run不是“测试模式”而是权限预检的终极武器--dry-run参数常被误解为“看看会不会报错”但它的真实价值远超于此。当你执行aws ec2 run-instances --image-id ami-0c55b159cbfafe1f0 --count 1 --instance-type t3.micro --dry-runCLI 并不会真的调用RunInstancesAPI而是调用RunInstances的DryRun变体。这个变体的特殊之处在于它会完整执行权限检查、配额检查、AMI 状态检查、子网可用性检查等所有前置校验但跳过资源创建步骤。这意味着--dry-run是你部署前的“红队渗透测试”。我在线上环境部署前必做三步权限验证aws iam simulate-principal-policy --policy-source-arn arn:aws:iam::123456789012:user/deployer --action-names ec2:RunInstances,ec2:CreateTags --resource-arns arn:aws:ec2:us-east-1:123456789012:instance/*。但这只能验证 IAM 策略不能验证实际执行时的上下文如是否在正确的 VPC 内。Dry-run 实战用真实参数跑一次--dry-run。它会告诉你“An error occurred (UnauthorizedOperation) when calling the RunInstances operation: You are not authorized to perform this operation.” 或 “An error occurred (InsufficientInstanceCapacity) when calling the RunInstances operation: There is no Spot capacity available that matches your request.” 这些错误信息比simulate-principal-policy更精准因为它包含了完整的执行上下文。成本预估虽然--dry-run不产生费用但结合aws ec2 describe-spot-price-history你可以估算 Spot 实例的预期价格波动。真正的“干运行”是成本、权限、容量的三维验证。实操心得我把--dry-run封装进所有自动化脚本的默认开关。例如一个部署脚本deploy.sh开头是DRY_RUN--dry-run if [[ $1 real ]]; then DRY_RUN fi aws ec2 run-instances $DRY_RUN --image-id $AMI_ID ...这样团队成员默认执行的是安全的 dry-run只有明确传入./deploy.sh real才会真实创建资源。上线三年零误操作事故。4. 高阶实战从单命令到可审计流水线的跨越4.1 用 CLI 构建跨账号资源同步的原子操作企业级 AWS 环境必然涉及多账号Production、Staging、Shared Services。一个常见需求是将 Shared Services 账号中的加密密钥KMS CMKID 同步到 Production 账号的 Lambda 函数环境变量中。手动复制粘贴不仅低效更致命的是缺乏审计追踪。以下是用 CLI 实现的原子化同步方案第一步在 Shared Services 账号中获取 KMS 密钥 ARN# 使用 shared-services profile 获取密钥 ARN KMS_ARN$(aws kms describe-key \ --key-id alias/prod-database-key \ --profile shared-services \ --query KeyMetadata.Arn \ --output text) echo Found KMS ARN: $KMS_ARN # 输出arn:aws:kms:us-east-1:111122223333:key/abcd1234-5678-90ab-cdef-1234567890ab第二步在 Production 账号中更新 Lambda 环境变量# 获取当前 Lambda 函数的环境变量保持原有变量不变 CURRENT_ENV$(aws lambda get-function-configuration \ --function-name prod-data-processor \ --profile production \ --query Environment.Variables \ --output json) # 构造新的环境变量 JSON注入 KMS_ARN NEW_ENV$(echo $CURRENT_ENV | jq --arg kms $KMS_ARN . {KMS_KEY_ARN: $kms}) # 更新函数配置注意此操作会触发 Lambda 版本发布 aws lambda update-function-configuration \ --function-name prod-data-processor \ --environment $NEW_ENV \ --profile production \ --dry-run # 先干运行验证第三步添加审计日志与失败回滚# 记录操作日志到 CloudWatch Logs需提前创建 log group LOG_ENTRY$(cat EOF { timestamp: $(date -u %Y-%m-%dT%H:%M:%SZ), operator: $(whoami), source_account: 111122223333, target_account: 222233334444, action: sync-kms-to-lambda, kms_arn: $KMS_ARN, lambda_function: prod-data-processor } EOF ) aws logs put-log-events \ --log-group-name /aws/cli/sync-audit \ --log-stream-name $(date -u %Y/%m/%d) \ --log-events [{\timestamp\:$(date -u %s000),\message\:\$LOG_ENTRY\}] \ --profile audit-logs这个流程的价值在于它把一个原本需要 5 个控制台页面跳转、3 次复制粘贴、0 审计记录的操作变成了一个可版本控制存入 Git、可定时执行cron、可失败回滚--dry-run 日志、可追溯责任人whoami 时间戳的原子单元。这才是 CLI 在企业级场景中的真实定位——不是替代控制台而是为控制台操作提供可编程、可审计、可自动化的骨架。4.2 解析 CLI 输出的黄金组合jqawksed的工业级用法AWS CLI 的--query功能强大但面对复杂嵌套结构时仍显吃力。比如你想从aws ec2 describe-vpcs的输出中提取每个 VPC 的 ID、CIDR、以及关联的 Tag:Name且按 CIDR 排序。--query可以做到但代码会变得难以维护# 复杂且难读的 JMESPath aws ec2 describe-vpcs \ --query sort_by(Vpcs[], CidrBlock).[].[VpcId,CidrBlock,tags[?KeyName].Value|[0]] \ --output json工业级做法是CLI 只负责获取原始数据jq负责结构化解析awk负责文本格式化sed负责最终清洗。完整流程# 1. 获取原始 JSON不加 --query保证数据完整性 RAW_JSON$(aws ec2 describe-vpcs --output json) # 2. 用 jq 提取关键字段并排序jq 是 JSON 专用解析器比 --query 更稳定 PARSED$(echo $RAW_JSON | jq -r .Vpcs[] | {vpc_id: .VpcId, cidr: .CidrBlock, name: (.Tags[]? | select(.KeyName) | .Value) // NO-NAME} | [.vpc_id, .cidr, .name] | tsv | sort -k2,2) # 3. 用 awk 格式化为对齐表格-F\t 指定 tab 分隔printf 控制列宽 echo $PARSED | awk -F\t { printf %-15s %-18s %s\n, $1, $2, $3 } | sed 1i\VPC ID CIDR BLOCK NAME # 输出 # VPC ID CIDR BLOCK NAME # vpc-0a1b2c3d 10.0.0.0/16 core-prod-vpc # vpc-0e5f6g7h 172.16.0.0/16 staging-shared这个组合的优势在于每一步都可单独测试、可调试、可复用。jq的错误信息明确如Cannot iterate over nullawk的字段索引直观$1,$2sed的插入操作简单。而如果全用--query一个括号错位就会导致整个命令失败且错误信息晦涩难懂。注意事项jq的-r参数至关重要。它输出“raw string”去掉 JSON 引号。如果不加-rjq .VpcId会输出vpc-0a1b2c3d带引号而aws ec2 describe-subnets --filters Namevpc-id,Values$VPC_ID中的$VPC_ID如果带引号API 会返回InvalidParameterValue。这是新手最常踩的坑之一。4.3 故障排查的终极心法从--debug日志中定位根因当aws s3 cp file.txt s3://my-bucket/报错An error occurred (AccessDenied) when calling the PutObject operation时90% 的人会立刻去查 IAM 策略。但真正的根因可能藏在--debug日志的第 37 行。我们来模拟一次深度排查aws s3 cp file.txt s3://my-bucket/ --debug 21 | grep -A5 -B5 AccessDenied在海量日志中关键线索往往出现在 HTTP 请求头部分2024-04-15 11:45:22,889 - MainThread - botocore.auth - DEBUG - Calculating signature using v4 auth. 2024-04-15 11:45:22,890 - MainThread - botocore.auth - DEBUG - CanonicalRequest: PUT /my-bucket/file.txt host:s3.us-west-2.amazonaws.com x-amz-content-sha256:e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 x-amz-date:20240415T114522Z host;x-amz-content-sha256;x-amz-date e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 2024-04-15 11:45:22,891 - MainThread - botocore.endpoint - DEBUG - Sending http request: AWSPreparedRequest stream_outputFalse, methodPUT, urlhttps://s3.us-west-2.amazonaws.com/my-bucket/file.txt, headers{User-Agent: baws-cli/2.13.15 Python/3.11.8 Darwin/23.3.0 source/x86_64 prompt/off command/s3.cp, X-Amz-Date: b20240415T114522Z, X-Amz-Content-SHA256: be3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855, Authorization: bAWS4-HMAC-SHA256 CredentialAKIA...XQ3A/20240415/us-west-2/s3/aws4_request, SignedHeadershost;x-amz-content-sha256;x-amz-date, Signature1234567890abcdef...} 2024-04-15 11:45:23,120 - MainThread - botocore.parsers - DEBUG - Response received: Response [403] 2024-04-15 11:45:23,121 - MainThread - botocore.parsers - DEBUG - Response body: b?xml version1.0 encodingUTF-8?\nErrorCodeAccessDenied/CodeMessageAccess Denied/MessageRequestId1234567890ABCDEF/RequestIdHostIdxyz.../HostId/Error这里的关键证据链是URL 是https://s3.us-west-2.amazonaws.com说明 CLI 正在向us-west-2区域发送请求。但你的 bucketmy-bucket实际创建在us-east-1。S3 的 bucket 名称全局唯一但每个 bucket 只存在于一个区域。向错误区域发请求必然AccessDenied而不是NoSuchBucket因为 bucket 名存在只是不在该区域。Authorization头中的CredentialAKIA...XQ3A/20240415/us-west-2/s3/aws4_request这证实了签名是按us-west-2区域生成的与 URL 一致。RequestId和HostId这两个值是 AWS 服务端的唯一追踪 ID。你可以把它提交给 AWS Support他们能精确查到这次请求在哪个边缘节点、哪个后端服务实例上被拒绝以及拒绝的具体策略规则如哪条 IAM 策略的哪一行导致了拒绝。所以真正的解决方案不是改 IAM 策略而是强制 CLI 使用正确的 regionaws s3 cp file.txt s3://my-bucket/ --region us-east-1 # 或者在 config 文件中为该 profile 设置 region实操心得我创建了一个aws-debug别名永久加入~/.zshrcalias aws-debugaws --debug 21 | grep -E (DEBUG|ERROR|WARNING|Error|RequestId) | tail -50这样遇到任何错误只需在原命令前加aws-debug就能快速聚焦关键日志节省 80% 的排查时间。5. 常见问题与独家避坑技巧实录5.1 “Unable to locate credentials” 的七种死法与解法这个错误是 AWS CLI 新手的第一道鬼门关。它看似简单实则背后有七种完全不同的根因必须逐一排除错误现象根本原因诊断命令解决方案Unable to locate credentials. You can configure credentials by running aws configure~/.aws/credentials文件不存在或为空ls -la ~/.aws/运行aws configure创建文件Unable to locate credentials. You can configure credentials by running aws configure文件存在~/.aws/credentials权限不是600ls -l ~/.aws/credentialschmod 600 ~/.aws/credentialsUnable to locate credentials--profile my-profilemy-profile只在config文件中定义未在credentials中声明aws configure list --profile my-profile在credentials中添加[my-profile]section或改用source_profile链接Unable to locate credentialsEC2 实例内实例未附加 IAM Role或 Role 无AmazonEC2ReadOnlyAccess等基础权限curl http://169.254.169.254/latest/meta-data/iam/security-credentials/为实例附加正确的 IAM RoleUnable to locate credentialsSSO 登录后aws configure sso后未执行aws sso login --profile my-sso-profileaws sts get-caller-identity --profile my-sso-profile先运行aws sso login获取临时凭证Unable to locate credentialsGitHub ActionsGitHub Secrets 中的密钥名称与env中引用的不一致echo KEY: ${{ secrets.AWS_ACCESS_KEY_ID }}检查 Secrets 名称拼写确保大小写完全匹配Unable to locate credentialsDocker 容器内宿主机~/.aws未挂载到容器或挂载路径错误docker run -it -v ~/.aws:/root/.aws:ro amazon/aws-cli whoami在docker run中添加-v ~/.aws:/root/.aws:ro独家技巧创建一个aws-cred-check脚本一键诊断所有凭证问题#!/bin/bash echo Credential File Check ls -la ~/.aws/ 2/dev/null || echo No ~/.aws directory cat ~/.aws/credentials 2/dev/null | head -5 echo -e \n Profile List aws
