AWS 的身份、权限和资源并不属于同一层。首次通过邮箱或 Google 账户登录,只完成了身份验证;真正访问云资源,还要经过账户、角色和临时会话等环节。

可以先用一条主线理解整个体系:

1
2
3
4
5
6
用户
→ 外部登录身份
→ AWS Organization 与 Account
→ Account 中的 IAM Role
→ STS 签发的临时 Session
→ 某个 Region 中的 Resource

AWS CLI 和开发工具还会在本地使用 Profile,保存认证入口、默认区域和相关配置。


Organization、Account 与 Project

AWS Organizations

AWS Organizations 用于集中管理多个 AWS Account,本身不承载网站、服务器或数据库。它主要提供:

  • 统一创建和管理成员账户。
  • 集中结算费用。
  • 按组织单元管理账户。
  • 通过 Service Control Policy(SCP)限定成员账户的最大权限。

典型结构如下:

1
2
3
4
5
AWS Organization
├── Management Account
├── Production Account
├── Development Account
└── Security Account

Management Account 是组织管理账户,负责组织级治理;其他账户称为 Member Account,通常承载具体业务。

SCP 不直接授予权限,只定义成员账户能够获得的权限上限。例如,组织可以用 SCP 禁止在指定区域之外创建资源。即使成员账户中的 IAM Role 拥有管理员权限,也不能突破 SCP 的限制。

AWS Account

AWS Account 是资源、权限、配额、费用和安全日志的基础隔离边界。每个账户都有全球唯一的 12 位 Account ID。

同一个身份可以访问多个账户,但这些账户中的资源彼此独立。进入错误账户时,即使选择了正确 Region,也看不到目标服务器。

Account ID 通常出现在 ARN 和跨账户授权中。它一般不被视为秘密,但公开材料仍可适当脱敏,减少不必要的环境信息暴露。

Project

AWS 部分新版注册与控制台体验使用 Project 作为面向业务的管理抽象,而不是直接向用户展示传统账户模型。

Project 可以包含独立的资源、权限和费用边界,底层仍通常由 AWS Account 提供隔离。启用完整组织能力后,已有 Project 可能作为 Member Account 纳入 AWS Organizations。

可以把二者理解为:

1
2
Project:面向用户的业务管理视图
Account:AWS 底层的资源与安全边界

外部身份、Federation 与 IAM Role

外部身份

通过 Google 登录 AWS 时,Google 只负责证明“你是谁”,并不直接决定资源属于哪个 AWS Account,也不决定你具有什么权限。

AWS 会将经过验证的外部身份映射到自己的身份与访问体系,再判断该身份可以进入哪些 Account、承担哪些 Role。

因此:

  • 一个 Google 身份可以获得多个 AWS Account 的访问资格。
  • 一个 AWS Account 可以授权给来自多个身份系统的用户。
  • 登录成功不等于拥有账户管理员权限。

Federation

使用外部身份访问 AWS 的机制称为 Federation,即身份联合。

用户先在 Google、企业身份平台或 IAM Identity Center 中完成认证,再获得目标 AWS Account 的临时访问权限。这样不需要在每个账户中分别维护长期用户名和密码。

IAM Identity Center 是 AWS 的集中身份访问服务,可以统一管理用户、用户组、账户访问关系和 Permission Set,并支持同一身份访问多个 AWS Account。

IAM Role 与 IAM Policy

IAM Role 是账户中的权限身份,可以被用户、服务或另一个账户临时承担。例如:

  • 只读审计角色。
  • 开发人员角色。
  • 网络管理角色。
  • 账户管理角色。

Role 本身表示“以什么身份访问”,IAM Policy 则描述这个身份允许或拒绝执行哪些 AWS API 操作。

1
2
IAM Role:权限身份
IAM Policy:权限规则

Role 不与某个用户永久绑定。多个身份可以承担同一个 Role,同一身份也可以在不同 Account 中承担不同 Role。即使两个账户都存在名为 AdministratorRole 的角色,它们也属于两个独立对象。


STS 与临时 Session

STS

AWS Security Token Service(STS)负责签发临时安全凭证。

当用户成功承担一个 IAM Role 后,STS 通常会签发:

  • 临时访问密钥 ID。
  • 临时访问密钥。
  • Session Token。
  • 过期时间。

临时凭证具有明确有效期,到期后必须重新认证或续期,因此比长期访问密钥更适合人员登录和跨账户访问。

Session

Session 是某个身份在一段有限时间内承担特定 Role 的结果。它同时确定:

1
2
3
进入哪个 AWS Account
承担哪个 IAM Role
临时访问何时过期

结束 Session 只会终止当前临时访问,不会删除 Account、Role 或云资源。后续重新登录会创建新的 Session。

Browser Multi-session

浏览器 Multi-session 允许同一浏览器同时保留多个 AWS 登录上下文,例如一个会话进入组织管理账户,另一个会话进入生产账户。

切换会话时,当前的 Account、Role 和临时凭证会一起变化。多个会话不代表创建了多个用户或多个账户,只是浏览器中并存的多个临时访问上下文。


AWS CLI Profile

Profile 是 AWS CLI、SDK 和开发工具保存在本地的命名配置。它可以记录:

  • 认证方式或登录会话引用。
  • 默认 Region。
  • 默认输出格式。
  • 承担 Role 所需的配置。

示例:

1
2
3
4
5
6
7
[profile production]
region = ap-northeast-1
login_session = <业务账户登录配置>

[profile organization-admin]
region = us-east-1
login_session = <管理账户登录配置>

productionorganization-admin 都只是用户定义的本地名称。创建 Profile 不会在 AWS 云端创建 Account、Role 或资源。

Profile、Session、Role 和 Account 的关系可以概括为:

1
2
3
4
5
6
7
8
Profile
→ 找到本地认证入口和默认配置
Session
→ 提供当前有效的临时凭证
Role
→ 定义本次访问的权限
Account
→ 确定访问的资源空间

Profile 可以长期保留,但关联的 Session 会过期。Session 过期后,Profile 仍然存在,只需重新认证。


Region、Availability Zone 与 Resource

Region

Region 是 AWS 在不同地理位置建设的独立云区域,例如:

1
2
3
4
东京        ap-northeast-1
新加坡 ap-southeast-1
悉尼 ap-southeast-2
弗吉尼亚 us-east-1

大多数 AWS 资源同时属于一个 Account 和一个 Region。因此,找不到资源时应先检查两个维度:

1
2
Account 是否正确
Region 是否正确

Availability Zone

一个 Region 通常包含多个 Availability Zone(AZ,可用区)。AZ 是相互隔离的数据中心集群,通过低延迟网络连接,但具有相对独立的电力、冷却和故障边界。

1
2
3
4
5
AWS
└── Region: Tokyo
├── Availability Zone A
├── Availability Zone B
└── Availability Zone C

高可用系统通常跨多个 AZ 部署,以减少单一故障域带来的影响。

Resource

Resource 是最终被创建和管理的云对象,例如:

  • EC2 虚拟机。
  • Lightsail 实例。
  • S3 存储桶。
  • RDS 数据库。
  • VPC 网络。
  • Lambda 函数。

一个资源通常由 Account、Region、服务类型和资源 ID 共同定位。少数服务和资源具有全局范围,不能机械地认为所有资源都属于某个 Region。


EC2 与 Lightsail

EC2 和 Lightsail 都能提供云服务器,但它们是两个独立的 AWS 服务。Lightsail 不是一种 EC2 实例类型,Lightsail 实例也不会显示在 EC2 控制台中。

维度 Amazon Lightsail Amazon EC2
产品定位 简化型 VPS 通用弹性计算平台
资源配置 固定套餐 高度可定制
网络能力 简化网络和防火墙 完整 VPC 网络体系
计费结构 套餐月费封顶,按小时累计 计算、存储和网络通常分别计费
扩展能力 适合单机和轻量服务 支持自动扩缩容和复杂架构
运维复杂度 较低 较高

Lightsail 适合个人网站、小型应用、开发环境和规模固定的轻量服务。EC2 适合需要复杂网络、多可用区、高可用、自动扩缩容或精细性能配置的系统。


ARN 资源标识

Amazon Resource Name(ARN)是 AWS 标识角色、策略和资源的标准格式。

例如:

1
arn:aws:lightsail:ap-northeast-1:123456789012:Instance/example

各部分含义如下:

1
2
3
4
5
6
arn                     ARN 标识
aws AWS 分区
lightsail 服务名称
ap-northeast-1 Region
123456789012 AWS Account ID
Instance/example 具体资源

部分全局资源的 ARN 中 Region 字段可能为空,不同 AWS 服务的资源部分格式也不完全相同。阅读 ARN 时,通常可以快速识别服务、账户、区域和具体资源。

Role Session 使用 STS 的 assumed-role ARN,通常包含 Account ID、Role 名称和 Session 名称。


完整访问模型

从外部身份登录到调用 AWS API,完整过程如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
用户
↓ 使用 Google、企业 IdP 等外部身份认证
身份联合或 IAM Identity Center
↓ 获得目标账户的访问资格
AWS Account
↓ 承担账户中的权限身份
IAM Role + IAM Policy
↓ 由 STS 签发临时凭证
Session
↓ 浏览器直接使用,CLI 可通过 Profile 定位
AWS API 请求
↓ 作用于指定账户和区域
Resource

Organizations 与 SCP 位于账户之上,负责限制成员账户的最大权限范围:

1
2
3
IAM Policy 为 Role 授权
SCP 限制成员账户可获得的权限上限
任何适用的显式 Deny 都会阻止请求

四个容易混淆的概念可以这样区分:

概念 作用
Account 决定资源归属和隔离边界
Role 定义可被临时承担的权限身份
Session 表示一次有期限的 Role 使用过程
Profile 保存本地认证入口和默认配置

新版 AWS 体验中的 Free、Paid 与 Advanced

新版 AWS 注册体验将账户计划和高级功能分成不同层次。具体资格、服务范围、区域限制和 credits 规则可能随时间与注册路径变化,应以当前官方文档和控制台为准。

Free Plan

Free Plan 面向学习、实验和概念验证场景,提供一定额度的 Free Tier credits,并限制可用服务范围。Project 通常会根据联系地址分配初始 Region;Project 创建后,修改联系地址不会自动改变这个 Region。

Paid Plan 采用按实际使用量计费,而不是收取固定订阅费。通过普通路径从 Free Plan 升级时,尚未过期且符合条件的 credits 通常可以继续抵扣费用。

如果账户因为加入 AWS Organization 或部署 AWS Control Tower 而升级,credits 的处理规则可能不同。因此,不能只根据“已经升级到 Paid Plan”判断 credits 是否保留。

Advanced 功能

Advanced 功能用于开放更完整的 AWS 服务、组织管理和多区域能力。激活后,已有 Project 可以作为 Member Account 纳入 AWS Organization,同时需要使用 AWS Budgets、Cost Explorer 和 Cost Anomaly Detection 等工具自行管理费用风险。

Advanced 激活具有不可逆性,执行前应确认计费和治理影响。

根据新版注册体验的官方说明,Lightsail 不属于 Free Plan 或普通 Paid Plan 的支持服务,通常需要先启用 Advanced 功能;在初始 Region 之外使用受区域限制的服务,也可能需要启用 Advanced 并调整组织级区域策略。

常见状态转换为:

1
2
3
Free Plan
→ Paid Plan
→ Advanced

启用 Advanced 后,组织中的 SCP 仍可能限制可用 Region。需要开放新区域时,应只在相关区域限制策略中加入实际需要的 Region,而不是一次性开放全部区域。


排查资源不可见问题

控制台或 CLI 中找不到资源时,可以按以下顺序检查:

1
2
3
4
5
6
7
1. 当前 Account 是否正确
2. 当前 Region 是否正确
3. 当前 Role 是否拥有查看权限
4. Session 是否已经过期
5. SCP 或 IAM Policy 是否存在显式 Deny
6. 当前查看的服务是否正确,例如 Lightsail 与 EC2
7. CLI 是否选择了正确的 Profile

这套顺序对应 AWS 最核心的访问边界,可以避免只在单一控制台页面中反复查找。


参考资料