在云计算飞速发展的今天，尤其是在 2026 年，自动化部署和程序化访问云资源已经不仅仅是开发者的必备技能，更是现代企业架构的基石。在我们最近的团队技术复盘会上，我们经常讨论这样一个核心问题：如何让本地的自动化脚本、CI/CD 流水线，甚至是我们正在构建的新一代 Agentic AI（自主代理），能够安全、高效地与 AWS 云服务进行通信？
答案的核心依然是我们今天要深入探讨的主题——AWS 访问密钥 和 秘密密钥。虽然在 2026 年，我们拥有了更加先进的 IAM Roles Anywhere 和 OIDC 联合认证，但理解 Access Key 的工作原理，依然是掌握 AWS 安全模型的必修课。
在这篇文章中，我们将一起探索这些凭据背后的工作原理，学习如何通过 AWS 管理控制台一步步生成它们，并重点讨论在 Vibe Coding（氛围编程） 和 AI 辅助开发日益普及的今天，如何确保这些敏感信息不泄露。无论你是刚开始接触 AWS 的新手，还是希望巩固安全最佳实践的老手，这篇文章都将为你提供详尽的实战指南。我们不仅要学会“怎么做”，还要明白“为什么这么做”，以确保我们在享受云计算便利的同时，固守安全底线。
AWS 访问凭证的核心：身份验证的钥匙
在深入操作之前，让我们先建立一个正确的认知：AWS 安全性的基石在于严格的身份验证。为了确保只有合法的用户和应用程序才能访问我们的云资源，AWS 使用了一套独特的凭据系统。这套系统主要由两部分组成，它们就像是一把钥匙的两侧，缺一不可。
#### 1. AWSACCESSKEY：你的公开身份
我们可以将 INLINECODEd21b35a2（访问密钥 ID）想象成是你的“用户名”或者“门牌号”。它的主要作用是唯一标识一个 IAM 用户或角色。当你发送一个 API 请求到 AWS 时，INLINECODE2856e9c2 会告诉 AWS “是谁在发这个请求”。虽然它被称为密钥，但在技术层面上，它是不需要绝对保密的（尽管我们建议不要随意分享），因为它本身不足以通过验证。它通常由 AWS 分配，格式固定，便于系统索引。
#### 2. SECRET_KEY：你的绝对机密
与访问密钥相对应的是 INLINECODE858bddfb（秘密访问密钥）。这才是真正的“密码”。INLINECODE1f4ef539 仅在创建 Access Key 时显示一次，之后 AWS 将不再保存明文。你的职责是将其妥善保管，绝不向任何人透露。当你的应用程序发起请求时，AWS 会使用这个秘密密钥来计算请求的 HMAC-SHA256 数字签名，从而确认你拥有该 AWS_ACCESS_KEY 对应的访问权限。
切记： 在 2026 年，攻击者利用 AI 扫描 GitHub 公开仓库以寻找泄露密钥的能力已大大增强。如果你的 Secret Key 泄露了，你的云资源可能在几分钟内处于危险之中。这两种密钥共同构成了编程访问 AWS 的基础。
访问方式解析：控制台 vs. 编程访问
在 AWS 生态中，根据使用场景的不同，我们将访问权限主要分为两类。理解这两者的区别，有助于我们更好地配置权限策略。
#### 控制台访问
这是我们最熟悉的登录方式。当你打开浏览器输入 AWS 管理控制台的网址时，你需要提供用户名和密码。这是为了让人眼与网页界面进行交互而设计的。
- 根用户：这是你在注册 AWS 账户时创建的超级管理员，拥有无限制的权限。出于安全考虑，我们强烈建议不要使用根用户进行日常操作，也不要为它创建访问密钥。
- IAM 用户：这是由管理员或根用户创建的具体用户账号。每个 IAM 用户都可以被分配特定的权限（如“只能读取 S3”，“只能重启 EC2”）。
#### 编程访问
这正是我们今天的重点。当你编写代码与 AWS 交互时，代码无法“输入密码”。因此，我们需要使用访问密钥。编程访问通常用于：
- 自动化运维：使用 Python 脚本自动备份数据库。
- 持续集成/持续部署 (CI/CD)：Jenkins 或 GitHub Actions 自动部署应用。
- Agentic AI 应用：2026 年的热点——你的自主 AI 代理直接连接到 AWS 服务（如分析 S3 中的日志数据）。
为了实现编程访问，我们必须为 IAM 用户生成 INLINECODEd178cc88 和 INLINECODEa907d6f7，并将它们配置在开发环境或应用配置中。
2026 年实战演练：如何创建 AWS 访问密钥和秘密密钥
理论讲完了，现在让我们卷起袖子，开始动手操作。考虑到 2026 年的 AWS 界面可能已经引入了更多 AI 辅助导航，但核心逻辑依然稳固。以下是创建密钥的详细步骤，我们会仔细检查每一个环节，确保你不会错过任何细节。
#### 步骤 1：登录控制台并进入安全凭证页面
首先，请登录到你的 AWS 管理控制台。登录成功后，请务必确认你当前是以 IAM 用户 身份登录的，而不是根用户。这是安全的第一道防线。
- 在控制台右上角的导航栏中，点击你的用户名/账户别名。
- 在下拉菜单中，选择 “安全凭据”。或者，你可以直接通过搜索栏搜索 "IAM"，进入服务控制台，点击左侧菜单的“用户”，选择你的用户名，再点击“安全凭据”选项卡。
> 友情提示：如果你是第一次点击安全凭据，系统可能会提示你返回 IAM 控制台来管理密钥，或者如果你是根用户登录，系统可能会警告你使用根用户存在的安全风险。请遵循最佳实践，使用 IAM 用户进行操作。
#### 步骤 2：创建访问密钥
在“安全凭据”页面中，你可以看到该用户的各种凭据信息。向下滚动到 “访问密钥” 部分。这里列出了当前已创建的所有密钥（如果有的话）。AWS 限制每个用户最多只能拥有 2 个激活的访问密钥，这是为了强制轮换和便于管理。
- 点击右上角的 “创建访问密钥” 按钮。
#### 步骤 3：最佳实践警告与设置（2026 版）
AWS 非常注重安全，因此在创建密钥前，通常会弹出一个关于“访问密钥最佳实践”的对话框。这里列出了三种使用场景：
- 命令行界面 (CLI)：如果你打算在本地电脑上运行 AWS CLI，请选择此选项。
- 编程访问：如果你使用的是 AWS SDK 或 API，请选择此选项。
- 第三方服务：如果你的应用运行在非 AWS 的平台上（如自建服务器或其他云提供商）。
> 重要说明：在 2026 年，AWS 甚至可能会提示你是否允许“AI 工具访问”。对于大多数初学者和标准应用，我们选择 “命令行界面 (CLI)” 或 “默认” 选项即可。确认无误后，点击 “下一步”。
#### 步骤 4：查看并下载密钥（关键时刻）
这是整个过程最重要的一步！系统成功生成密钥后，屏幕上会显示一个包含以下信息的对话框：
- 访问密钥 ID：一串类似于
AKIAIOSFODNN7EXAMPLE的字符。 - 秘密访问密钥：一串随机生成的复杂字符串，例如
wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY。
请注意：秘密访问密钥（SECRET_KEY）仅在此时此刻显示一次！一旦你关闭或离开这个页面，你将永远无法再次查看它。如果你弄丢了它，你只能删除它并重新创建一个新的。
强烈建议的操作：点击 “下载 .csv 文件” 按钮将凭据保存到本地，或者将其安全地复制并粘贴到密码管理器（如 1Password 或 AWS Secrets Manager）中。保存好后，点击 “完成”。
代码实战：从 Vibe Coding 到生产级部署
现在我们手里有了密钥，让我们看看如何在真实的开发环境中使用它们。我们不仅要看基础用法，还要结合 2026 年的开发习惯——即AI 辅助编程（Vibe Coding）和容器化部署。
#### 场景一：配置 AWS CLI（基础但必要）
如果你喜欢使用命令行工具，我们需要将刚刚获取的 Access Key ID 和 Secret Access Key 配置到 AWS CLI 中。这是我们进行一切自动化操作的前提。
命令示例：
# 1. 运行配置命令
aws configure
# 2. 系统会提示你输入以下信息
AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE # 在此输入你的 Access Key
AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY # 在此输入你的 Secret Key
Default region name [None]: us-east-1 # 输入你常用的区域，如 us-east-1
Default output format [None]: json # 输出格式，可选 json, text 或 table
#### 场景二：生产级 Python 代码（Boto3 深度实践）
让我们看一个更实际的例子。假设你正在编写一个 Python 脚本，需要列举 S3 存储桶。在现代开发中，我们绝对不能硬编码密钥。我们将展示如何利用环境变量和重试机制来编写健壮的代码。
代码示例：
import boto3
import os
from botocore.exceptions import ClientError, EndpointConnectionError
# 从环境变量中读取凭据（2026年标准做法）
# 这样做的好处是，你的代码可以无缝迁移到 Docker 容器或 CI/CD 流水线中
ACCESS_KEY = os.getenv(‘AWS_ACCESS_KEY_ID‘)
SECRET_KEY = os.getenv(‘AWS_SECRET_ACCESS_KEY‘)
REGION_NAME = ‘us-east-1‘
# 创建一个 S3 客户端对象
# 注意：在生产环境中，我们通常不直接传参，而是让 boto3 自动寻找链式凭据
# 但为了演示清晰，这里显式传入
s3_client = boto3.client(
‘s3‘,
region_name=REGION_NAME,
aws_access_key_id=ACCESS_KEY,
aws_secret_access_key=SECRET_KEY
)
def list_all_buckets_with_retry():
"""
带有重试机制的存储桶列举函数
在实际网络环境中，网络波动是常态，重试机制至关重要。
"""
print("正在尝试连接 AWS 并获取 S3 存储桶列表...")
try:
# 调用 list_buckets API
response = s3_client.list_buckets()
# 打印结果
print(f"找到 {len(response[‘Buckets‘])} 个存储桶:")
for bucket in response[‘Buckets‘]:
print(f"\t- {bucket[‘Name‘]}")
except ClientError as e:
# 捕获 AWS 错误，例如权限不足或凭据错误
error_code = e.response[‘Error‘][‘Code‘]
if error_code == ‘InvalidAccessKeyId‘:
print("错误：你的 Access Key ID 无效，请检查配置。")
elif error_code == ‘SignatureDoesNotMatch‘:
print("错误：你的 Secret Key 错误，请检查配置。")
else:
print(f"发生 AWS 错误: {e}")
except EndpointConnectionError:
print("错误：无法连接到 AWS 端点，请检查你的网络连接。")
except Exception as e:
print(f"发生未知错误: {e}")
if __name__ == "__main__":
list_all_buckets_with_retry()
深入讲解：
在这段代码中，我们使用了 INLINECODEaebe34fd 来获取凭据，这是防止密钥泄露的第一道防线。同时，我们引入了 INLINECODE62dea57c，这是处理 AWS API 异常的标准方式。如果你直接复制这段代码到 Cursor 或 Windsurf 等 AI IDE 中，你可以尝试让 AI 帮你添加“分页逻辑”或“过滤特定前缀的存储桶”，这能极大提升开发效率。例如，你可以这样对 AI 说：“请在上述代码中添加一个功能，只显示名称包含 ‘prod- 的存储桶，并计算它们的总大小。” 这就是 Vibe Coding 的魅力所在。
#### 场景三：本地开发环境变量配置
我们可以在不修改代码的情况下，通过配置环境变量来运行上面的脚本。
在 Linux/macOS 上：
export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
# 运行脚本
python3 your_script.py
2026 年最佳实践：超越 Access Key
虽然我们现在讲的是如何创建 Access Key，但作为负责任的技术专家，我们必须告诉你：在 2026 年，长期凭证正在逐渐被淘汰。让我们思考一下未来的方向。
#### 1. 使用 OIDC 和 IAM Roles（现代化的选择）
如果你的代码运行在 GitHub Actions、GitLab CI 或者 AWS 内部的 EC2/ECS 上，你完全不需要创建 Access Key。
- GitHub Actions 示例：使用 OIDC (OpenID Connect)。你可以在 GitHub 的 Workflow 文件中配置一个
role-to-assume，AWS 会信任 GitHub 的身份提供者。这样，你的 CI/CD 流程会自动获得一个临时的 Role 凭据，有效期通常只有 1 小时。这比长期密钥安全得多。
# .github/workflows/deploy.yml 示例片段
permissions:
id-token: write # 这是 OIDC 必须的权限
contents: read
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Configure AWS Credentials
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789012:role/GitHubActionRole
aws-region: us-east-1
# 后续步骤可以直接运行 aws s3 cp ... 无需设置 key
#### 2. 密钥轮换自动化
如果你必须使用 Access Key（例如在本地开发环境），请务必设置轮换策略。虽然 AWS 没有提供“自动轮换”的按钮，但我们可以使用 Lambda 函数 结合 Step Functions 或者使用 AWS CLI 脚本来实现。
手动轮换的最佳实践：
- 创建新密钥：做“状态 1”激活。
- 测试新密钥：更新你的环境变量，运行测试脚本。
- 停用旧密钥：确认无误后，在控制台将旧密钥设为“非活动”。
- 观察期：等待 24-48 小时，确认业务未受影响（监控 CloudTrail 中的调用记录）。
- 删除旧密钥：确认无误后，永久删除旧密钥。
#### 3. 安全左移与供应链安全
在现代 DevSecOps 流程中，我们强调“安全左移”。这意味着密钥管理应该在代码编写阶段就被考虑。
- 预提交钩子：我们可以使用 INLINECODE4a3a601d 或 INLINECODE5e08df21 在代码提交前扫描，防止 Access Key 被意外上传到 GitHub。配置非常简单：INLINECODE3c317f3f 和 INLINECODEde924b12。
常见错误与解决方案
在创建和使用访问密钥的过程中，即使是经验丰富的开发者也可能遇到一些陷阱。让我们看看如何避免它们。
- “我的密钥在哪？我找不到它了！”
* 问题：这是新手最常遇到的问题。你创建完了，点击了“关闭”，然后发现忘了保存。
* 解决方案：AWS 官方出于安全考量，不会允许你再次查看 Secret Key。你只能回到“安全凭据”页面，将该密钥设为“非活动”状态，然后创建一个新的。请务必在创建时下载 CSV 文件。
- 报错：
InvalidClientTokenId
* 问题：当你运行代码时，系统返回“请求中包含的安全令牌无效”。
* 原因：通常是你复制的 INLINECODE36dd28cf 或 INLINECODE3e3c9cf8 有多余的空格，或者你在不同的 AWS 账户下登录了 CLI。
* 解决方案：仔细检查你复制的字符串，确保没有多余的空格。同时确认你的 AWS CLI 配置的用户是创建该密钥的用户。
结语
创建 AWS 访问密钥和秘密密钥是开启 AWS 自动化之旅的第一步。虽然过程看似简单，但背后涉及的安全机制却非常严密。我们希望这篇教程不仅帮助你成功创建了密钥，更重要的是，让你意识到了凭证管理的重要性。
现在，你手里已经握着通往云端的钥匙了。你可以尝试配置本地环境，运行你的第一个 AWS CLI 命令，或者编写你的第一个自动化脚本。在 2026 年及未来，记住，能力越大，责任越大，保护好你的 SECRET_KEY，就是保护你在云端的数据资产。祝你在 AWS 的探索之旅中一切顺利！