备考助手
AWS 开发基础（Developer Fundamentals）
很多人学 DVA 一上来就想学 Lambda、DynamoDB、API Gateway，结果写着写着就卡在三件事：
- 权限为什么拒绝
- 本地能跑，云上不行
- 一上流量就报错
这章的目标不是背概念，而是先把“开发调用 AWS 的底层逻辑”一次讲明白。
先看一条真实调用链（你后面所有章节都在复用）
你的代码
-> AWS SDK/CLI
-> 凭证来源（Credential Provider Chain）
-> IAM 权限评估
-> 目标服务 API（S3 / DynamoDB / Lambda...）
-> 成功或报错
-> CloudWatch / CloudTrail 观测
你后面遇到的 80% 问题，都能在这条链路里定位。
1. 第一件事：身份和权限先分开
身份是什么？
“谁在调用 AWS API”。
权限是什么？
“这个身份可以调用哪些 API、操作哪些资源”。
图解说明：
- 这张图在讲什么：开发调用链里的身份主体和权限规则关系。
- 你应该先看哪里：先看 Role，再看 Policy，因为程序大多数用 Role。
- 考试怎么问：经常问“为什么不用长期 Access Key”“为什么同一份代码在不同环境权限不同”。
给初学者的结论
- 人（开发者）可以用 User/SSO
- 程序（Lambda/ECS/EC2）优先用 Role
- 不要把长期密钥写在代码里
2. 第二件事：凭证到底从哪里来
很多“本地通、线上挂”的根因是凭证来源不一致。
常见凭证来源顺序（记忆版）
| 优先级（常见） | 来源 | 典型场景 |
|---|---|---|
| 1 | 环境变量 | CI/CD、容器注入 |
| 2 | 本地 profile 文件 | 本地开发 |
| 3 | AssumeRole / SSO 会话 | 多账户开发 |
| 4 | 运行时角色（EC2/ECS/Lambda） | 云上生产 |
考试不会强抠 SDK 的每个细节顺序，但会考“哪种方式更安全、更可运维”。
最常用 CLI 流程
aws configure --profile dev
aws sts get-caller-identity --profile dev
第一条是配置，第二条是确认“你现在到底是谁”。
3. 第三件事：为什么推荐 STS 临时凭证
长期 Access Key 像“永不过期的门禁卡”，泄露代价很大。
STS 临时凭证像“限时访客证”，过期自动失效。
典型场景
- 本地开发临时切换到测试账户
- CI/CD 跨账户部署
- 临时排障需要短期权限
aws sts assume-role \
--role-arn arn:aws:iam::123456789012:role/DVAAppRole \
--role-session-name local-dev-session
初学者最容易踩的坑
- AssumeRole 成功，但业务调用仍失败：Role 本身权限不够
- 偶发 403：会话过期
- 跨账户一直失败：Trust Policy 没放行调用方
4. 第四件事：错误处理不是“加重试”这么简单
DVA 高频报错你要会“分类处理”。
| 错误 | 本质问题 | 第一检查点 |
|---|---|---|
AccessDenied | 权限 | IAM Policy / Resource Policy |
InvalidAccessKeyId | 凭证 | profile/环境变量是否正确 |
ExpiredToken | 会话 | STS 会话是否过期 |
ThrottlingException | 限流 | 重试策略 + 退避 |
ResourceNotFoundException | 资源定位 | Region / ARN / 名称 |
正确重试思路
- 只对可重试错误重试（如限流、短暂网络错误）
- 使用指数退避 + jitter
- 不要对权限错误无限重试
import random
import time
def backoff_sleep(attempt, base=0.2, cap=10):
time.sleep(min(cap, base * (2 ** attempt) + random.uniform(0, 0.3)))
5. 第五件事：观测要跟上（否则你永远靠猜）
CloudWatch 负责“看现在”
- Metrics：趋势（延迟、错误率、吞吐）
- Logs：细节（具体报错、请求上下文）
- Alarm：触发通知
CloudTrail 负责“查责任链”
- 谁在什么时候调用了哪个 API
- 特别适合追
AccessDenied和越权操作
图解说明：
- 这张图在讲什么：API 调用审计链路。
- 你应该先看哪里：先看 principal，再看 action，再看时间线。
- 考试怎么问：问“如何审计调用历史、定位权限拒绝来源”。
6. 一张选型表：遇到场景直接选
| 场景 | 推荐方案 | 原因 |
|---|---|---|
| 本地开发调试 | Profile + AssumeRole | 接近企业真实流程 |
| Lambda 访问 DynamoDB | Lambda Execution Role | 无需硬编码密钥 |
| ECS 访问 S3 | ECS Task Role | 最小权限、易审计 |
| 跨账户只读审计 | STS AssumeRole | 临时凭证更安全 |
| 密钥管理 | Secrets Manager | 支持轮换，不写死在代码里 |
7. 章节小测（按实战思路）
- 本地可调用 S3，部署到 ECS 后失败，第一步应该查什么？
- A. S3 存储类型
- B. ECS Task Role 权限
- C. CloudFront 配置
- D. Route53 记录
答案：B
- 遇到
ThrottlingException，最合理处理是？
- A. 立即循环重试
- B. 指数退避 + jitter
- C. 直接忽略
- D. 关闭日志
答案：B
- 需要跨账户访问资源且不想长期密钥，优先方案是？
- A. 共享 root 账号
- B. 新建长期 IAM User
- C. STS AssumeRole
- D. 把密钥写进代码
答案：C
8. 本章你必须带走的 4 句话
- 程序身份优先 Role，不要长期 Access Key。
- 先确认“我是谁”，再排权限。
- 权限错不要盲目加
*，先看调用链最小动作。 - 没有 CloudWatch/CloudTrail，就等于闭眼排障。