云资源控制台：从资源申请到删除证据的开发闭环

云资源控制台的证据闭环高清原图

测试缓存已经停了，账单为什么还在增长

一次接口压测需要临时缓存。开发者从浏览器收藏夹进入云控制台，搜索“缓存”，选择看起来最便宜的规格，放通自己的公网地址，复制密码到本地配置，验证完便把实例停机。几轮迭代后，控制台里出现三个同名实例：一个在开发账号，一个在共享订阅，另一个在相邻区域。原申请人只记得资源名，不记得账号、资源组和区域；停机实例仍保留磁盘、备份或公网地址；费用中心里的标签为空；审计记录只能看到有人修改过网络规则，却无法关联工单。

这不是“按钮点错了”这么简单。云资源控制台同时跨过身份、组织层级、计费、地域、配额、网络和数据控制面。页面里选中的每一个下拉框，都可能改变资源归属、可见性、连接路径、故障半径和账单。创建成功只说明控制面接受了请求，不说明应用能连接、权限足够、数据可以进入，也不说明删除主资源后费用会归零。

处理这类现场，先不要急着再次创建。把现有资源详情导出或抄录为一条资源记录，至少包含：厂商、组织或租户、账号/订阅/项目、资源组、区域/可用区、资源类型、不可变 ID、owner、用途、到期信号、网络入口、密钥引用、依赖、删除保护、计费方式和最近一次审计事件。缺少其中任一项，都应先做只读调查，而不是凭同名资源猜测。

先分清六种边界，控制台才不会把人带偏

“我在正确的项目里”不能只靠页面左上角的名字判断。名称可以重复、可以改，浏览器标签页也可能保留旧会话。真正决定归属的是一组不可变标识与继承关系。

需要回答的问题	它控制什么	常见误判
我以谁的身份进入	能查看、创建、修改和删除哪些对象	把 SSO 登录成功当成已获得资源权限
资源归哪个组织、租户或目录	上级策略、身份信任、集中审计	只看个人账号，不看组织成员关系
费用落在哪个账号、订阅、项目或计费账号	预算、账单、配额和责任	把资源组当成独立账单边界
资源在哪个区域、可用区或位置	数据驻留、延迟、可用规格和网络路径	只记录服务名，不记录 region/zone
资源组和标签如何组织对象	生命周期、检索、授权或成本归集	假设各云“资源组”语义相同
VPC、子网、端点和密钥在哪	数据面连通与应用认证	控制面创建成功后直接把故障归因于密码

AWS 的组织层级是 Organization、root、OU 与 account，业务资源归属于具体账号；AWS 官方的多账号组织指南还特别建议严格控制 management account，并避免在其中承载业务工作负载。AWS Resource Group 通常通过标签查询或 CloudFormation stack 形成逻辑成员集合，官方Resource Groups 说明展示的 ARN 本身也包含 region 与 account，因此它不是 Azure Resource Group 的同义词。

Azure 的治理链通常从 Microsoft Entra tenant、management group、subscription 进入 resource group 与 resource。Azure Resource Manager 是控制台、CLI、REST 和 SDK 共用的管理层；官方Resource Manager 概念页说明上级作用域的策略与访问设置会向下继承。Resource Group 是生命周期和管理容器，但组内资源可以位于不同 location，组本身的位置还用于保存部署元数据，不能把“资源组位置”误认为所有资源的数据驻留位置。

Google Cloud 的 Organization、Folder、Project 与服务资源构成继承树。Project 是启用 API、管理 IAM 与创建多数资源的基本上下文，而且 display name、project ID、project number 是不同字段；这些差异在官方资源层级说明中有明确对象模型。Billing Account 是单独的计费对象，Project 只是与它建立计费关联，不能把 Project ID 当成 Billing Account ID。清理脚本只保存显示名，可能查询不到或命中错误对象。

阿里云以资源目录、文件夹和成员账号组织多账号，账号是资源归属、计量计费与安全隔离单元；单账号内部再用资源组和标签管理。官方资源目录、资源组与标签关系明确指出三者隔离级别和授权方式不同。腾讯云的标签可跨地域、跨资源类型做分类检索，可从官方标签文档入口确认目标产品是否支持。华为云的企业项目可以组织多个区域的资源，但 IAM project、region 与具体服务配额仍需分别核对；企业项目不能替代区域和资源 ID。

因此，团队不要发明一个叫 project 的模糊字段兼容所有云。保留厂商原生字段，再额外加内部 workload 或 ticket 作为关联键。控制台展示名服务于人，不可变 ID 服务于自动化与审计，两者都要记录。

进入控制台之前先启用正确的入口

云控制台通常不需要在本机安装，但“能打开网页”不等于服务可用。浏览器应通过团队批准的身份入口进入，优先使用企业 SSO、MFA 与角色切换；普通开发会话不使用组织根账号、Azure tenant 的高权管理员、Google Cloud Organization 管理员或国内云主账号执行资源创建。共享账号和共享浏览器 profile 会让审计主体失真，也会把登录缓存、下载的密钥文件和多个环境混在一起。

第一次进入目标作用域时按下面顺序做只读检查：

从身份菜单复制当前 principal/role，以及账号、subscription 或 project 的不可变 ID；不要截图包含邮箱、手机号、完整资源清单的整页。确认组织、tenant 或 resource directory 的名称和 ID，与工单批准的父级一致。选择明确的 region/zone/location，打开目标服务的区域与规格页面，确认服务、SKU、网络能力和密钥托管能力在该位置可用。

检查服务是否需要显式启用。Azure 某些服务依赖 resource provider 注册，官方资源提供程序说明可以查询 provider 状态、资源类型、位置和 API 版本；Google Cloud 项目通常要先启用对应 API；国内云有些产品也要求开通服务或完成授权。

检查创建权限和外围权限是否同时存在。创建缓存实例的权限，不自动包含创建 VPC、修改安全组、读取密钥、查看账单、移除资源锁或查询审计的权限。

不要为了省一次申请而给个人绑定全局 Contributor、Owner 或 Administrator。最小角色至少应拆成申请人、资源创建者、网络审批者、密钥读取者、费用查看者和删除批准者；小团队可以由同一个人承担多个职责，但审计记录里仍要看得出每个动作使用了什么角色。必须临时提权时，记录会话角色、授权作用域和失效条件，不把长期 AK/SK、client secret 或 token 粘进浏览器便签、脚本参数与截图。

控制台 UI 会调整，菜单名称也会本地化。团队操作手册应固定“对象与证据”，例如 subscription ID、provider registration、project number、region、resource type、operation name，而不是固定“左侧第几个菜单”。这样页面改版后，判断链仍然成立。

用资源申请契约挡住错误账号和错误区域

创建前先把需求写成机器可读的资源申请契约。它不是 IaC state，也不保存任何 secret；它负责让评审者在资源产生费用前看见范围、容量、网络、数据和退出条件。下面的 JSON 使用明显占位符，可保存为 cloud-resource-request.json，再由工单、仓库脚本或 CI 做静态校验。

cloud-resource-request.json

{
  "schemaVersion": "cloud-dev-resource/v1",
  "ticket": "<ticket-id>",
  "provider": "<aws|azure|gcp|aliyun|tencent|huawei>",
  "scope": {
    "organizationRef": "<organization-or-directory-reference>",
    "workloadScope": {
      "type": "<account|subscription|project>",
      "ref": "<native-workload-scope-reference>"
    },
    "billingAccountRef": "<billing-account-reference>",
    "resourceContainer": {
      "type": "<resource-group|folder|logical-query>",
      "ref": "<native-container-or-query-reference>"
    },
    "region": "<approved-region>",
    "zone": "<approved-zone-or-not-applicable>"
  },
  "resource": {
    "type": "<managed-cache-resource-type>",
    "name": "<team>-<service>-dev-cache-<suffix>",
    "sku": "<small-approved-sku>",
    "expectedHours": 8,
    "dataClass": "synthetic-only"
  },
  "tags": {
    "owner": "<team-alias>",
    "environment": "dev",
    "purpose": "<ticket-id>",
    "cost-center": "<cost-center-code>",
    "expires-at": "<T-plus-duration>"
  },
  "network": {
    "vpcId": "<approved-vpc-id>",
    "subnetId": "<approved-subnet-id>",
    "endpointMode": "private",
    "source": "<approved-runner-or-cidr-placeholder>"
  },
  "identity": {
    "createRole": "<temporary-create-role>",
    "runtimeIdentity": "<workload-identity>",
    "secretRef": "<secret-manager-reference>"
  },
  "protection": {
    "deleteProtection": true,
    "backupRequired": false,
    "deletionApprover": "<approver-role>"
  },
  "cost": {
    "estimateUrl": "<approved-pricing-estimate-url>",
    "currency": "<billing-currency>",
    "maxEstimatedAmount": "<approved-amount>"
  }
}

这些字段故意不压成一个通用 project。AWS 和国内云通常以 account 承载资源归属，Azure 以 subscription 承载资源并把 resource group 作为生命周期容器，Google Cloud 以 Project 承载服务资源、再单独关联 Billing Account。workloadScope.type 保留原生边界类型，ref 在受控系统中解析为不可变 ID；resourceContainer 则明确区分生命周期容器和逻辑查询。expires-at 不能是自由文本“用完删除”；它需要能被库存任务解释为绝对时间或经批准的到期规则。标签中不放邮箱、客户名、内部域名、工单正文、访问密钥或数据内容，因为标签会进入账单、库存、审计和多种检索索引。AWS 官方也在Resource Groups 标签说明中明确提醒不要把 PII 与机密信息存进标签。

资源名称负责可读性，资源 ID 负责唯一性。创建响应返回后，把 provider resource ID、创建 operation/request ID、实际 region/zone、实际 SKU 和创建状态追加到独立的 cloud-resource-evidence.json，不要回写覆盖申请值。申请值与实际值并存，才能发现控制台默认值漂移。

区域、配额和容量要在创建按钮之前核算

区域选择至少同时考虑六件事：调用方位置、数据驻留要求、目标服务是否可用、所需 SKU 是否有容量、VPC 与依赖是否同区、价格和网络流量费。离开发者最近的区域未必离 CI runner、测试数据库或企业出口最近；服务名称相同，也不表示所有区域支持相同规格、私网端点、备份能力和加密选项。

配额不是账户余额。它可能是不可调整的系统限制，也可能是账号、subscription、project、region、zone、SKU、vCPU、IP、磁盘、端点或 API 速率某一维度上的可调整 quota。Google Cloud 官方Cloud Quotas 概览把 quota 区分为 global、regional 与 zonal，并说明项目、folder 和 organization 的值可能不同。Azure 的订阅与服务限制入口也区分 Resource Manager、subscription、resource group 和各服务限制。阿里云则通过Quota Center 服务索引进入各产品的配额与限制。

创建前记录四个数：请求量、当前使用量、硬上限、创建后的剩余量。只看“还有 2 个”没有意义，因为你不知道这是区域配额、全局配额还是某个规格族配额。共享开发环境还要预留故障恢复余量；把 quota 用到满值，会让扩容、替换和蓝绿验证同时失败。

价格也不能写成团队 Wiki 里的固定单价。SKU、region、操作系统、存储、备份、快照、公网 IP、出站流量、请求次数、日志、密钥调用、税费、折扣与购买承诺都会改变总额。创建前用目标租户能看到的正式价格页或计算器生成估算：AWS 可用Pricing Calculator，Azure 使用官方价格计算器，Google Cloud 使用Pricing Calculator。计算器输出是估算，不是最终账单；Google Cloud 的计算器页面也明确提示估算可能与月度账单不同。

开发缓存的容量不要只填“最小规格”。先估算峰值 key 数、平均 value 大小、协议与索引开销、复制份数、连接数、吞吐和测试持续时间，再选择能证明行为的最小 SKU。最小规格如果不支持私网、TLS、备份关闭或目标引擎版本，实验会验证错误的架构。反过来，为一次连接测试申请高可用、多可用区和长期保留备份，会把学习实验变成持续费用。

正反实验要证明策略真的挡得住错误

第一轮实验不直接触碰云 API，而是在本地验证申请契约。把下面脚本保存为 scripts/check-cloud-resource-request.mjs。它只读 JSON，不访问网络，也不读取环境变量中的凭据。模板检查使用 --template，只验证结构；实际申请必须去掉该参数，并把占位符替换为受控引用。

scripts/check-cloud-resource-request.mjs

import { readFile } from 'node:fs/promises'

const file = process.argv[2]
const templateMode = process.argv.includes('--template')
if (!file) throw new Error('usage: node scripts/check-cloud-resource-request.mjs <request.json>')

const request = JSON.parse(await readFile(file, 'utf8'))
const errors = []
const requiredTags = ['owner', 'environment', 'purpose', 'cost-center', 'expires-at']
const placeholder = /^<[^<>]+>$/

if (request.schemaVersion !== 'cloud-dev-resource/v1') errors.push('unsupported schemaVersion')
if (!request.scope?.workloadScope?.type) errors.push('missing workloadScope.type')
if (!request.scope?.workloadScope?.ref) errors.push('missing workloadScope.ref')
if (!request.scope?.billingAccountRef) errors.push('missing billingAccountRef')
if (!request.scope?.region) errors.push('missing region')
if (!templateMode && !['account', 'subscription', 'project'].includes(request.scope?.workloadScope?.type)) {
  errors.push('invalid workloadScope.type')
}
if (!templateMode) {
  const unresolved = []
  const visit = (value, path = '$') => {
    if (typeof value === 'string' && placeholder.test(value)) unresolved.push(path)
    else if (Array.isArray(value)) value.forEach((item, index) => visit(item, `${path}[${index}]`))
    else if (value && typeof value === 'object') {
      Object.entries(value).forEach(([key, item]) => visit(item, `${path}.${key}`))
    }
  }
  visit(request)
  if (unresolved.length) errors.push(`unresolved placeholders: ${unresolved.join(', ')}`)
}
if (request.resource?.dataClass !== 'synthetic-only') errors.push('development experiment accepts synthetic-only data')
if (request.network?.endpointMode !== 'private') errors.push('endpointMode must be private')
if (!request.protection?.deleteProtection) errors.push('deleteProtection must be enabled at creation')
if (!request.identity?.secretRef) errors.push('missing secretRef')
for (const key of requiredTags) {
  if (!request.tags?.[key]) errors.push(`missing tag: ${key}`)
}

if (errors.length) {
  console.error(JSON.stringify({ ok: false, errors }, null, 2))
  process.exitCode = 2
} else {
  console.log(JSON.stringify({
    ok: true,
    provider: request.provider,
    region: request.scope.region,
    resource: request.resource.name,
    tags: requiredTags
  }, null, 2))
}

先验证模板，预期返回 ok: true、退出码 0。再复制为 cloud-resource-request.dev.json，把工作负载作用域、计费账号、区域和资源容器替换成受控引用；不带 --template 运行也必须通过。第二次通过只证明申请字段已经解析，不证明云权限、区域容量或资源可用。

node --version
node scripts/check-cloud-resource-request.mjs cloud-resource-request.json --template
node scripts/check-cloud-resource-request.mjs cloud-resource-request.dev.json
echo $?

反向实验复制一份请求为 cloud-resource-request.invalid.json，把 endpointMode 改为 public，删除 owner，把 dataClass 改为 customer-copy。再次执行时，输出应同时包含三类错误，退出码应为 2。如果校验器只报第一项便退出，批量修复效率会很低；如果校验器自动补默认 owner 或 region，则会把责任和位置错误藏起来。

node scripts/check-cloud-resource-request.mjs cloud-resource-request.invalid.json
# 预期特征：ok=false、endpointMode、synthetic-only、missing tag: owner

第二轮才进入批准的测试作用域。正向实验依次创建资源组或逻辑分组、最小资源、私网端点/安全规则和 secret 引用，随后完成一次写入与读取；反向实验先保持数据面网络拒绝，确认应用得到超时或连接拒绝，再仅开放批准来源并复测。反向实验的价值是证明默认拒绝有效，不是故意用真实密码反复撞认证，也不是对公网端点做扫描。

如果组织没有标签策略或创建门禁，控制台可能允许无标签资源成功创建。此时“创建成功”反而是反向证据：把资源 ID 加入修复队列，在连接测试前补齐标签，并推动策略 owner 建立创建时阻断。Azure 官方标签说明提醒资源不会自动继承 resource group 或 subscription 的标签，需要 Azure Policy 等机制实施继承；不要看到组上有 owner 就假设子资源已经进入费用归集。

网络和密钥要按数据面重新设计

控制台走的是管理面，应用连接走的是数据面。你能从公网浏览器创建私网缓存，并不意味着本机能访问它。连接路径至少经过调用方进程、DNS、代理或企业出口、VPN/专线、路由、VPC/子网、网络 ACL 或防火墙、安全组、负载入口、TLS、服务认证与应用协议。任何一层失败，都可能被客户端压缩成“连接超时”。

开发资源优先使用 private endpoint、私网 IP 或 VPC 内地址，让批准的 CI runner、跳板开发环境或受管工作站进入同一网络。需要临时公网入口时，来源必须是审批后的固定出口占位符 <approved-cidr>，规则带 owner 与到期标记，不允许 0.0.0.0/0 或 ::/0 配合数据库、缓存和管理端口。Azure 的NSG 设计指南建议使用 service tag 与 application security group 表达逻辑来源，避免硬编码会变化的服务 IP。

网络规则与 IAM 是两道门。网络可达但 principal 没有数据面权限，应得到明确的认证或授权拒绝；IAM 有权限但路由不通，则通常超时。排障时不要同时修改网络、密码、TLS 和客户端版本，否则一次成功无法说明是哪项修复生效。

密钥只保存引用，不保存值。应用配置使用 Secret Manager、Key Vault、KMS 关联服务或团队批准的密钥系统，运行时身份读取 secret；开发者不把密码从控制台复制进仓库、镜像、shell history 或 CI 日志。AWS 的Secrets Manager 最佳实践要求最小权限、轮换、监控并降低 CLI 暴露风险；Azure 的Key Vault RBAC 指南区分控制 vault 的管理动作与读取 secret 的数据动作。创建资源的人不应天然获得读取所有应用 secret 的权限。

下面的项目配置只有引用，没有凭据。endpoint 也使用部署系统注入的内部 DNS 名占位符，避免真实域名进入示例和日志。

config/application-dev.yaml

cache:
  endpoint: ${CACHE_ENDPOINT:<private-endpoint.example.com>}
  port: ${CACHE_PORT:<service-port>}
  tls: true
  username: ${CACHE_USERNAME:<workload-identity-name>}
  passwordSecretRef: ${CACHE_PASSWORD_SECRET_REF:<secret-manager-reference>}
  connectTimeoutMs: 3000
  operationTimeoutMs: 2000
cloudResource:
  provider: ${CLOUD_PROVIDER:<provider>}
  workloadScopeRef: ${CLOUD_WORKLOAD_SCOPE_REF:<account-subscription-or-project-reference>}
  billingAccountRef: ${CLOUD_BILLING_ACCOUNT_REF:<billing-account-reference>}
  region: ${CLOUD_REGION:<approved-region>}
  resourceId: ${CLOUD_RESOURCE_ID:<immutable-resource-id>}

日志只打印 provider、region、资源 ID 的受控短摘要、解析到的地址类型、TLS 协议、响应状态和耗时，不打印连接串、Authorization header、session token、secret value、签名 URL 与完整内部 DNS。debug 模式也不能改变这条底线。

连接验证要从名字走到一次最小读写

“控制台状态是 Running”只说明服务控制器认为资源已进入目标状态。连接验证要逐层推进，每一步只改变一个变量，并保存预期与失败证据。

# 使用占位符；不要把真实 secret 放在命令行参数中
$Endpoint = "<private-endpoint.example.com>"
$Port = <service-port>

Resolve-DnsName $Endpoint
Test-NetConnection -ComputerName $Endpoint -Port $Port -InformationLevel Detailed

# 仅适用于目标服务公开了 HTTPS health/API 入口的情况
curl.exe --fail-with-body --connect-timeout 3 --max-time 8 `
  "https://$Endpoint`:$Port/<health-path>"

DNS 阶段应看到目标私网地址或批准的 CNAME 链；解析成意外公网地址时立即停止，不要靠 hosts 文件强行覆盖。TCP 阶段成功只能证明端口可建立连接，不证明 TLS 和认证。TLS 阶段检查证书链、主机名与协议，不用 -k、--insecure 或全局关闭证书校验制造假成功。认证阶段使用运行时身份和 secret 引用，预期无权限 principal 得到稳定拒绝，批准 principal 才能通过。

最后执行一个带唯一前缀的合成键写入、读取和删除，例如 <ticket-id>:connectivity:<random-suffix>。预期写入返回成功状态，读取值与 checksum 一致，删除后再次读取返回 not found。不要导入生产快照、客户数据或真实账号资料来“提高真实性”；连接实验需要真实链路，不需要真实敏感数据。

失败证据应至少含：资源 ID 摘要、region、调用方环境、解析结果类型、目标端口、TLS 错误类别、服务错误码、request/correlation ID 和相对发生顺序。出现超时时先查 DNS、路由与规则命中；出现证书名称不匹配先查 endpoint 是否选错；出现 403、AccessDenied 或等价错误再查数据面角色；出现 quota 或 capacity 错误回到目标 region 的配额与 SKU 可用性。不要把一次 ping 不通当成服务不可达，托管服务可能根本不响应 ICMP。

把项目和脚本接到资源记录，而不是接到某个人

应用仓库需要的是稳定的资源契约，不是某位开发者电脑上的控制台会话。部署系统从环境清单读取 provider、原生工作负载作用域、独立计费账号引用、region 和 resourceId，从密钥系统读取 secret，从网络基线获得 endpoint；本地开发通过受控代理或临时身份进入。任何环境都不应依赖“先让某个人登录控制台并复制密码”。

资源创建完成后生成下面这种证据摘要。它可以进入受控工单或制品库，但仍不含完整账号、内网端点和 secret。真实 ID 若属于内部敏感资产，应由访问受控系统保存，公开日志只保留哈希或末尾短摘要。

cloud-resource-evidence.json

{
  "ticket": "<ticket-id>",
  "requestDigest": "<sha256-of-approved-request>",
  "scope": {
    "provider": "<provider>",
    "workloadScopeRef": "<controlled-account-subscription-or-project-reference>",
    "billingAccountRef": "<controlled-billing-account-reference>",
    "region": "<approved-region>",
    "resourceContainerRef": "<controlled-native-container-or-query-reference>"
  },
  "resource": {
    "resourceRef": "<controlled-immutable-resource-reference>",
    "operationId": "<create-operation-or-request-id>",
    "state": "available",
    "sku": "<actual-sku>"
  },
  "verification": {
    "dns": "private-address-confirmed",
    "tcp": "reachable-from-approved-runner",
    "tls": "hostname-and-chain-verified",
    "auth": "workload-identity-accepted",
    "roundTrip": "synthetic-write-read-delete-passed"
  },
  "cleanup": {
    "deleteProtection": true,
    "candidateAfter": "<T-plus-duration>",
    "approver": "<approver-role>"
  }
}

CI 只消费 resourceRef 和 secretRef，不接受资源显示名作为唯一输入。流水线开始时做只读 preflight：比较实际身份、作用域与 region；查询资源 ID 是否存在、标签是否完整、状态是否允许连接；检查到期标记尚未越界。任一项不一致就拒绝，不尝试在相邻账号或区域搜索同名资源后继续。

控制台适合首次发现、观察状态和人工审批；当同类资源需要重复创建、跨环境保持一致或接受代码评审时，应迁移到 IaC。迁移并不意味着删除控制台入口，控制台仍用于只读调查和受控紧急操作；但资源定义、依赖、标签、锁和销毁计划应由版本化声明接管。避免控制台与 IaC 同时修改同一字段，否则下一次 apply 可能覆盖人工修复，或者把漂移当成预期状态。

排障时从失败证据反推所属控制面

现象	第一判断	常见原因	修复后再验证
控制台看不到已知资源	身份、账号、region、过滤器	登录了相邻 tenant；region 错；资源类型不在当前视图	用不可变 ID 在批准范围做只读搜索
创建按钮灰色或 API 拒绝	IAM、上级策略、provider/API 启用	缺 create 权限；SCP/Policy/组织策略拒绝；服务未启用	查询 effective policy 与 provider/API 状态
quota exceeded	quota 名称与维度	查了全局值，实际耗尽区域/规格配额	记录 usage/limit/dimension 后缩容或申请调整
SKU 列表为空	region、zone、capacity、账号能力	SKU 不在该区；订阅类型受限；库存不足	换批准规格或区域，重新估价与评审依赖
创建成功但连接超时	DNS、路由、防火墙、安全组	endpoint 为私网但调用方不在网络；来源规则过期	从批准 runner 重做 DNS 与 TCP 测试
TCP 通但 TLS 失败	endpoint 与信任链	使用 IP 连接导致主机名不匹配；企业 CA 未安装	使用正式 DNS，修复 CA 后去掉 insecure 选项
TLS 通但认证拒绝	数据面身份和 secret	只获控制面角色；secret 版本过期；运行时身份错误	用无权/有权 principal 做稳定正反验证
无法删除	锁、保护、依赖、保留策略	删除保护开启；子资源仍附着；策略要求审批	输出依赖图，审批后按逆序删除
主资源已删但费用仍有	派生资源或账单延迟	磁盘、快照、备份、IP、日志、密钥、承诺仍计费	查资源级明细与后续账期，不凭页面消失结案

跨账号搜索默认只读。AWS 可用Resource Explorer按名称、标签、ID 和 region 搜索支持的资源，但索引完整性、权限和支持资源类型会影响结果，不能把“搜索无结果”直接当成“资源不存在”。阿里云 Resource Center 也支持跨服务、跨地域检索，但账号与资源目录权限仍决定可见范围。任何全局库存都应记录扫描了哪些账号与区域、哪些服务不受支持、索引更新时间和查询条件。

排障修复坚持一次只改一个层面。把 region、网络规则、密码和 SKU 一起改掉，会失去因果证据；直接授予 Owner/Administrator 虽可能让错误消失，却无法证明最小权限。真正的修复结果应包括正向通过和反向仍被拒绝：批准 runner 可连接，未批准来源仍超时；运行时身份能读指定 secret，普通开发角色不能列出其他 secret；创建者能查看资源，不能自行移除审批锁并删除。

删除保护之前先画出依赖图

云资源很少是一个孤立方框。缓存实例可能依赖 VPC、子网、安全组、私网 DNS、参数组、KMS key、secret、监控告警、日志目标和备份策略；它还可能被应用配置、CI 变量、服务发现、IaC state、预算规则和审计导出引用。只删除主实例，会留下费用和敏感副本；先删除共享网络或 key，又会破坏其他资源。

删除保护也不是统一能力。Azure management lock 可在 subscription、resource group 或 resource 上施加 CanNotDelete 或 ReadOnly，并且锁会覆盖用户权限、继承到下级资源；它只约束控制面，不能阻止数据面删除。Azure 官方的资源组删除顺序与错误处理要求先移除组上及下层资源的锁和相关备份保护，但 Resource Manager 仍会按依赖逐个发起同步或异步删除；组删除不是可以依赖事务回滚的原子操作，失败后必须按资源 ID 重新盘点。Google Compute Engine 的 VM deletion protection 默认关闭，且不会阻止项目整体终止、实例内 shutdown 或某些组管理动作，详见官方防止意外删除说明。AWS 与国内云要按具体服务检查 termination/deletion/release protection，不能假设账号级存在一个通用开关。

创建时开启保护，退出时按受控流程解除。保护的作用是增加意图确认，不是让资源永久不可清理。资源记录中至少写清：保护类型、作用域、谁能移除、移除需要什么批准、移除后多长时间必须完成删除，以及失败时如何重新加锁。

删除前生成依赖清单，并标记每个对象是“独占、共享、派生、外部引用”中的哪一种：

<resource-id> managed-cache [独占]
  -> <subnet-id> [共享，不删除]
  -> <security-rule-id> [独占，删除]
  -> <private-dns-record-id> [独占，删除]
  -> <secret-ref> [派生，吊销版本并按保留策略删除]
  -> <backup-id> [派生，按数据等级决定保留或删除]
  -> <log-destination-id> [共享，删除该资源流与索引，不删除共享目的地]
  <- <application-config-ref> [外部引用，先下线]
  <- <ci-variable-ref> [外部引用，先移除]

Azure 删除 Resource Group 会删除其中资源；任一资源的删除锁会阻断整个操作，托管资源组则应从拥有它的服务入口删除。AWS 删除 Resource Group 通常不会等价删除成员资源；阿里云官方删除资源组说明要求组内没有资源，先把可迁移资源移到其他组，再按各产品生命周期单独处理不能迁移的资源，默认资源组也不能删除。看到同一个“Delete group”按钮，后果可能完全不同。

清理与回滚必须先证明归属再执行

清理脚本最危险的写法，是按名称模糊匹配后批量删除。安全脚本必须要求调用者同时提供 provider、billing scope、region、不可变 resource ID、owner 标签、purpose 标签和批准号；先查询，输出待删对象及依赖，默认 dry-run；只有所有字段与批准记录完全一致，才允许进入 apply。跨账号、跨 region 和无 owner 对象默认拒绝。

cleanup contract

export CLOUD_PROVIDER="<provider>"
export CLOUD_BILLING_SCOPE_ID="<account-subscription-or-project-id>"
export CLOUD_REGION="<approved-region>"
export CLOUD_RESOURCE_ID="<immutable-resource-id>"
export EXPECTED_OWNER="<team-alias>"
export EXPECTED_PURPOSE="<ticket-id>"
export CLEANUP_APPROVAL="<approval-id>"

# 厂商 CLI 由对应团队适配；第一步只能是只读 describe/get。
./scripts/cloud-resource-cleanup --mode plan --request cloud-resource-request.json

# 人工核对身份、范围、资源 ID、标签、依赖和锁后，才允许执行。
./scripts/cloud-resource-cleanup --mode apply --approval "$CLEANUP_APPROVAL"

plan 输出应包含当前 principal、scope、region、资源完整 ID、标签差异、保护状态、依赖列表、预计删除对象和明确保留对象。任何字段为空都应失败，不允许自动选择“第一个匹配项”。apply 开始前再次查询，防止 plan 与执行之间资源被修改；这是控制台场景里的基本竞态保护。

删除顺序通常是：停止应用写入并移除服务发现；确认合成数据无需保留；撤销 CI/应用引用；处理备份与快照；移除独占 endpoint、DNS 和安全规则；吊销 secret 版本；审批解除删除保护；删除主资源；等待异步 operation 到终态；再次做跨区域库存查询。共享 VPC、子网、KMS key、日志桶和审计 trail 不随单个实验删除。

回滚有两种。尚未开始删除时，回滚是恢复锁、取消 cleanup job、恢复应用引用；删除已提交且服务不可恢复时，回滚不是“撤销删除”，而是依据申请契约重新创建新 ID 的资源，再恢复允许保留的合成配置。不能承诺所有云资源都可 undelete。Google Compute Engine 的实例删除说明要求逐项确认附加磁盘的自动删除设置，以及保留磁盘、预留静态 IP、reservation 和购买承诺各自的生命周期与费用；删除 VM 不等于这些对象都会停止计费。

清理完成的判断也不是控制台列表里消失。至少要取得删除 operation 成功、按 ID 查询为 not found、独占依赖清零、网络规则撤销、secret 吊销、审计事件可查、成本视图进入预期收敛状态七类证据。异步删除处于 Deleting、Pending 或等价状态时，只能记录“已提交”，不能结案。

审计记录和费用复核要追到删除之后

审计回答“谁以什么身份，从哪里，对哪个资源，发起了什么控制面动作，结果如何”。业务日志回答服务处理了什么数据，网络流日志回答流量是否经过，账单回答哪些计量项产生费用；四者不能互相替代。一次资源实验至少保存 create、网络规则变更、标签修改、删除保护变更、delete 的 operation/event/request ID，并用 ticket 与受控资源引用关联。

AWS CloudTrail 会记录控制台和 API 的控制面事件；AWS 官方Resource Groups 与 CloudTrail 集成说明指出即使没有自建 trail，仍可在 Event history 查看近期事件，而持续交付需要配置 trail。Azure Activity Log 默认收集资源创建、更新、删除等控制面事件，官方Activity Log 说明同时提醒普通读取通常不在其中，长期保留需通过 diagnostic setting 导出。阿里云 ActionTrail、腾讯云操作审计与华为云 CTS也提供控制台/API 操作追踪与长期转储入口；具体留存、数据事件覆盖和转储费用应在目标账号重新确认。

审计日志自身也可能包含 principal、源 IP、资源 ID、请求参数和错误详情，访问权限不能因为它“只是日志”就放宽。导出到对象存储或日志服务后，还会新增存储、索引、查询、跨区传输和保留费用。删除业务资源不应删除证明其创建与删除的审计证据，但到期后要按合规策略清除，不做无限保留。

费用复核分三次。创建前保存估算与假设；资源运行中按 resource ID、service、region、tag、resource group 或 project 检查用量是否符合持续时间与 SKU；删除后继续观察后续账单，直到主资源计量停止，并解释仍存在的合法费用。标签进入费用系统可能有处理延迟，所以刚补标签后看不到分摊，不等于标签无效，也不能反向证明费用为零。

复核时逐项查计算/实例时长、存储与快照、备份、静态公网 IP、负载入口或私网端点、出站流量、日志摄入与留存、密钥存储与调用、监控、自定义镜像，以及 reservation/commitment/包年包月等购买承诺。预算告警是滞后信号，不是实时熔断；停机也不等于停止所有计费。账单没有资源级 ID 时，用 operation 时间、region、SKU、标签和成本中心交叉定位，并把无法分摊的共享成本交给明确 owner。

架构决策看隔离、迁移和故障半径

开发资源放在哪一层，决定了权限、配额、费用和事故影响。个人沙箱适合短时、无共享依赖、纯合成数据的学习实验，但 owner 离开时必须自动回收；团队开发账号或 subscription/project 适合共享依赖和 CI，要求命名、标签、预算与审计统一；生产账号不应承载随手实验，即使资源名带 dev 也不会自动获得开发隔离。

账号、subscription 或 project 是强隔离边界时，能分开 IAM、quota、billing 和策略，代价是跨边界网络、镜像、密钥、日志与共享服务更复杂。资源组和标签是较轻的组织方式，适合在同一计费边界内管理生命周期或检索，但不能替代账号级隔离。VPC 和 subnet 解决网络路径，不解决谁能调用控制面 API；KMS key 和 secret store 解决密钥边界，不解决费用归属。把这些概念压成一个“项目”字段，会让后续迁移无法判断影响面。

区域决策也不只是延迟。跨区访问可能引入传输费、数据驻留问题、配额分裂、备份复制与故障切换复杂度。开发环境若与依赖跨区，会把连接实验变成跨区网络实验；若为了便宜随意换区，可能验证不到生产所需的 endpoint、加密和规格能力。合理做法是先定义批准区域集合，再让项目根据依赖、数据等级、容量和价格选择其中一个，禁止脚本静默 fallback 到“任意可用区域”。

控制台创建适合一次性探索，但当资源包含多个依赖、多人重复操作或需要可重建时，声明式 IaC 更可靠。Service Catalog、组织模板或内部开发平台适合把 SKU、region、网络、标签、预算和删除保护收敛成批准产品；它们提高一致性，却不能替代底层审计与账单。自动化平台失败时，团队仍要能从原生控制台按不可变 ID 查询状态、读取 operation error、检查锁与依赖。

选择管理方式时问五个问题：资源能否从声明重建；是否需要跨账号共享；数据能否迁移；删除是否可恢复；费用能否归属到 owner。无法回答其中任一项，就还不具备长期共享条件，应保持小规格、短时长、合成数据和强删除保护。

长期治理靠库存、门禁和退出演练

一套可持续的控制台基线至少包含四个自动循环。创建门禁检查批准 scope、region、SKU、标签、私网、数据等级、估算和删除保护；连接门禁从批准 runner 验证 DNS、TCP、TLS、身份与最小读写；库存任务按账号与区域扫描资源、依赖、owner、到期、锁和最后活动；费用任务把账单与资源记录对齐，发现无标签、已过期、停机仍计费和删除后残留对象。

库存不能只扫“正在运行的实例”。还要覆盖 stopped/deallocated 资源、磁盘、快照、备份、镜像、IP、endpoint、DNS、日志、secret、KMS key、监控、reservation 与承诺。扫描器先产生候选，不直接删除：无标签可能是治理缺陷，不是可删除证明；最后访问为空可能是日志未启用，不是从未使用；owner 离职则应转入责任接管，不是立刻销毁共享资源。

团队每个周期复查这些指标：

申请记录与实际资源能否一一对应，是否存在影子账号和未知区域。必填标签创建时合规率、后补延迟和费用系统可见率。配额使用率与恢复余量，是否存在单个实验耗尽共享 quota。

公网入口、宽来源规则、长期密钥和未轮换 secret 数量。到期未清理、停机仍计费、无 owner 与删除保护长期解除的资源。创建、网络变更、解锁与删除事件能否按 ticket 和资源 ID 追溯。

删除后派生资源清零时间、账单收敛时间和清理失败重试次数。

升级治理也适用于控制台。厂商会调整 UI、API 版本、默认网络、可用区域、SKU、标签能力、审计覆盖和价格。团队模板不要写死某次页面布局与永久单价；每次变更前从目标租户的区域、quota、provider/API、权限和价格入口重新确认，再用固定正反实验验证。新能力先进入专用测试 scope，不直接扩大组织策略和全局权限。

退出演练应真正走一次 plan：选择一个合成数据资源，证明能找到 owner、应用引用、网络依赖、secret、锁、审计和费用；在不执行删除的 dry-run 中得到完整逆序计划；经批准后才在测试作用域完成清理，并验证后续库存与费用收敛。演练若只能依赖原创建者记忆，说明资源记录还没有成为团队资产。

当任何开发者都能在变更前回答“我是谁、我在哪个计费与区域边界、我要创建什么、谁能连接、费用如何计算、哪些对象会残留”，并在退出后拿出 not found、依赖清零、凭据吊销、审计事件和费用收敛证据，云资源控制台才真正成为研发工具，而不是一组难以追责的网页按钮。