安全组引用怎么用
授权对象可以直接填另一个安全组 ID，表示「允许来自该安全组内所有实例的流量」。这样应用层扩缩容、更换 IP 都不需要调整数据库侧的规则，是分层架构里比写 IP 段更稳的做法。它把权限绑定到角色而不是地址：谁被归入应用层安全组，谁就自动获得对应访问权，也天然减少了遗留放行条目。
分层引用示例
分层引用示例
数据库安全组 sg-db 入方向规则：
协议 TCP 端口 3306 授权对象 sg-app
效果：sg-app 组内新增实例后自动获得数据库访问权限
无需修改 sg-db 的任何规则
注意：出方向也要对应放行，反向引用不要漏配基本信息
| 用法 | 授权对象填写安全组 ID，而不是 IP 段 |
|---|---|
| 适用范围 | 同账号同地域内（跨账号能力以厂商文档为准） |
| 收益 | 成员变化自动生效，减少漏配与遗留放行 |
| 依赖关系 | 被引用组删除后引用规则失效 |
典型使用场景
- 三层架构：Web 组访问应用组、应用组访问数据组，逐层引用而不写 IP
- 弹性伸缩：伸缩组实例频繁更换，用引用避免每次改数据库规则
- 微服务分层：按服务角色划安全组，调用关系用引用表达
- 减少密钥扫描风险：不再需要维护一长串内网 IP 授权对象
写 IP 与写引用对比
| 维度 | 引用安全组 | 写 IP 网段 |
|---|---|---|
| 成员变化 | 自动生效 | 需手工维护 |
| 可读性 | 能看出角色关系 | 只有地址 |
| 误放行风险 | 随角色收敛 | 历史条目易残留 |
| 适用边界 | 同账号同地域 | 跨账号跨地域 |
引用关系形成依赖链：调整安全组归属或删除安全组前，先确认引用方。
规模化后的维护
引用会让规则数量随角色增长而不是随机器数量增长，这正是它在规模上去之后依然可维护的原因。代价是依赖关系变得隐蔽：被引用的组一旦被删除或改名，引用方会静默失效。建议把引用关系画成一张分层图（谁是调用方、谁是被调用方）放进文档，并在变更涉及安全组时先查这张图，确认改动不会牵连上游业务。