AWS账号关闭前的资源清理清单：避免注销后还在出账

很多人处理 AWS账号注销 时，第一反应是去找“关闭账号”的入口。入口确实重要，但在实际运维里，更容易出问题的不是点不点得下去，而是账号里还有没有资源、账单有没有结清、组织关系有没有处理干净。

AWS 账号一旦用于测试、部署、POC 或团队项目，里面可能留下 EC2、EBS、S3、RDS、NAT Gateway、Elastic IP、CloudWatch Logs 等资源。它们不一定都显眼，但有些会持续计费。直接做 AWS账号关闭，后面再发现账单异常或资源没备份，就会很被动。

下面按发布前检查清单的方式，把注销前该看的点梳理一遍。更适合开发者、运维同学或企业技术负责人在真正关闭账号前对照执行。

先确认：你要关闭的是哪类 AWS 账号

AWS 账号一般有两种常见情况：

一种是独立账号，也就是没有加入 AWS Organizations，或者你只管理这一个账号。
另一种是组织内成员账号，账号挂在某个管理账号下面，费用和策略可能由组织统一管理。

这两种账号的处理方式不完全一样。

如果是独立账号，通常需要使用账号根用户进入 Billing / Account 相关页面完成关闭操作。注意，这里说的是根用户，不是普通 IAM 用户。很多团队平时只用 IAM 账号登录，真正要关闭账号时，才发现根用户邮箱、MFA 或密码没人保管。

如果是 AWS Organizations 里的成员账号，需要先确认组织管理账号是否有关闭成员账号的权限，以及该成员账号是否还有业务依赖。不要只在成员账号里看资源，还要从组织维度检查账单、SCP、集中日志和共享网络配置。

企业里最常见的坑，是“以为这是个没人用的测试账号”，结果里面还有 CI/CD 凭证、日志归档、Route 53 记录或者跨账号角色。关闭前最好找项目负责人、财务和运维一起确认一次。

关闭账号之前，先把资源盘一遍

做 AWS关停资源 时，不建议只看 EC2 控制台。AWS 的资源分散在不同区域、不同服务里，只查一个区域很容易漏。

比较稳妥的顺序是：先看账单，再看资源，再处理数据。

从账单反推高风险资源

进入 Billing 之后，先看最近几个月的费用分布。重点关注这些服务：

• EC2
• EBS
• S3
• RDS / Aurora
• NAT Gateway
• Elastic Load Balancing
• CloudWatch
• Route 53
• Data Transfer
• Lambda
• ECR
• OpenSearch
• ElastiCache

账单里如果某个服务最近仍有费用，说明账号里大概率还有资源或流量。不要只看当月总额，最好展开到服务维度、区域维度。

有些资源平时不容易被注意到，例如：

• 没挂载到实例上的 EBS 卷
• EBS Snapshot
• 未释放的 Elastic IP
• NAT Gateway
• Load Balancer
• RDS 自动备份或快照
• S3 里的历史对象
• CloudWatch Logs 长期保留
• Route 53 Hosted Zone
• ECR 镜像仓库

这些资源单个看金额可能不大，但账号放久了就会形成持续费用。

EC2 不只是关机，还要看卷、IP 和镜像

很多人以为把 EC2 实例 stop 掉就结束了。实际上，停止实例只能避免实例运行费用，EBS 卷还在，Elastic IP 如果处于未绑定状态也可能产生费用，快照和 AMI 也可能继续占用存储。

建议按这个顺序检查：

1. 进入 EC2 控制台，切换所有用过的 Region；
2. 查看 Instances，确认是否还有 running / stopped 实例；
3. 查看 Volumes，处理不再需要的 EBS 卷；
4. 查看 Snapshots，确认是否还需要保留；
5. 查看 Elastic IPs，释放不用的公网 IP；
6. 查看 AMIs，删除不再使用的自定义镜像；
7. 查看 Load Balancers 和 Target Groups；
8. 查看 NAT Gateways。

NAT Gateway 是测试账号里很容易漏掉的资源。很多团队搭 VPC 时顺手创建，后来 EC2 都删了，NAT Gateway 还在跑。做账号注销前，这类网络资源一定要单独查一遍。

如果你习惯用 AWS CLI，也可以辅助排查，例如按区域查实例：

aws ec2 describe-instances --region ap-southeast-1

查 EBS 卷：

aws ec2 describe-volumes --region ap-southeast-1

查 Elastic IP：

aws ec2 describe-addresses --region ap-southeast-1

命令只是辅助，重点是别只盯默认区域。AWS 资源是按 Region 分布的，关闭账号前最好把历史用过的区域都扫一遍。

数据类服务先备份，再删除

账号关闭不是“清空回收站”。在动数据类服务前，先确认有没有业务数据、日志数据、合规留存要求。

常见需要重点看的服务包括：

• S3
• RDS / Aurora
• DynamoDB
• EFS
• ECR
• OpenSearch
• CloudWatch Logs
• Backup
• Glacier / S3 Glacier 相关存储

S3 尤其要小心。测试账号里经常会有部署包、日志、导出文件、静态资源、备份文件。删除 Bucket 前，要先确认对象是否已经迁移或不再需要。

RDS 也一样。删除数据库前，至少确认三件事：

• 是否需要最终快照；
• 是否还有应用连接；
• 是否涉及生产、测试或客户数据。

如果只是临时测试库，删除前也建议把连接信息、实例名、库名和负责人记录下来。以后排查历史问题时，这些记录很有用。

IAM、Access Key 和第三方集成别忘了断开

AWS账号关闭前，还要检查身份和权限相关配置。

很多项目会把 AWS Access Key 配在 GitHub Actions、GitLab CI、Jenkins、服务器环境变量、Kubernetes Secret、Terraform 后端配置里。账号关闭后，这些任务可能开始报错，但报错信息不一定直观。

建议逐项确认：

• IAM 用户是否还在被 CI/CD 使用；
• Access Key 是否还在外部系统中配置；
• IAM Role 是否被其他账号 AssumeRole；
• 是否有跨账号信任关系；
• 是否有 Terraform、Pulumi、CDK 等 IaC 工具还指向该账号；
• 是否有监控系统、日志系统、备份系统依赖该账号。

如果团队有统一的配置中心或密钥管理平台，也要同步清理相关凭证。否则账号虽然关了，但无效凭证还留在系统里，后面会增加排查成本。

Route 53、域名和 DNS 要单独确认

Route 53 容易被忽略，但它往往影响线上访问。

如果账号里有 Hosted Zone，关闭账号前要确认：

• 域名是否仍在使用；
• DNS 解析是否需要迁移；
• NS 记录是否已经改到新的 DNS 服务；
• 是否有生产域名解析仍指向该账号管理的记录；
• 域名注册是否也在这个账号下。

不要在没有迁移 DNS 的情况下直接删除 Hosted Zone。对外部用户来说，DNS 解析异常比一台测试机没关更严重。

如果只是废弃项目，也建议导出或截图保存解析记录，避免以后有人问“这个域名以前指向哪里”时完全无从查起。

账单、发票和付款方式要在关闭前处理好

技术同学往往关心资源，财务同学更关心账单和票据。真正要做 AWS账号注销，这两边都要对齐。

关闭前建议确认：

• 当前账单是否已经出完；
• 是否还有未支付费用；
• 是否有 Savings Plans、Reserved Instances 或其他长期承诺；
• 是否需要下载历史账单；
• 是否需要保存发票或付款记录；
• 企业报销、入账、审计材料是否已经归档。

如果账号属于企业项目，不建议由个人技术同学单独关闭。至少要让财务或账号负责人确认一次账务状态，避免后面出现“账号关了，但账单材料没保存”的情况。

真正关闭 AWS 账号时注意什么

资源清理、数据备份、账务确认都处理完之后，再进入账号关闭流程。

一般来说，独立账号需要使用根用户登录 AWS 管理控制台，在账户相关页面找到关闭账号的入口。关闭时 AWS 会要求确认账号信息，并提示关闭后的影响。实际入口和页面文案可能会调整，具体以 AWS 控制台当前显示为准。

这里有几个细节要提前知道：

第一，关闭账号不是普通 IAM 用户能随便操作的事。
如果根用户邮箱、密码或 MFA 丢失，需要先恢复根用户访问权限。

第二，账号关闭后仍可能存在一个保留或恢复窗口。
AWS 对关闭账号通常会有一定的后续处理周期，期间账号和资源状态会受到限制。具体规则以 AWS 官方最新文档为准，不要把“关闭账号”理解成所有历史痕迹立刻消失。

第三，关闭前产生的费用仍然需要处理。
即使账号已经提交关闭，如果之前有资源使用、税费、承诺类费用或未结清账单，仍要按账单规则处理。

第四，关闭账号不等于完成数据治理。
如果公司对数据留存、删除、审计有要求，关闭前就要把备份、导出、销毁记录做好。不要把这一步留到账号关闭之后。

一个更稳的注销前检查顺序

如果不想漏项，可以按下面这个顺序走：

1. 确认账号归属：独立账号还是 Organizations 成员账号；
2. 找到根用户访问方式，确认 MFA 可用；
3. 查看最近几个月 Billing，定位仍有费用的服务；
4. 按 Region 检查 EC2、EBS、EIP、NAT Gateway、ELB；
5. 检查 S3、RDS、DynamoDB、EFS、ECR 等数据服务；
6. 备份需要保留的数据，记录删除动作；
7. 清理 IAM 用户、Access Key、跨账号 Role；
8. 检查 CI/CD、监控、日志、备份系统是否还依赖该账号；
9. 迁移或删除 Route 53、域名、DNS 配置；
10. 下载账单、发票和必要的财务记录；
11. 确认无未处理费用和业务依赖；
12. 使用根用户或组织管理方式执行账号关闭；
13. 关闭后继续关注后续账单通知和邮箱提醒。

这套流程看起来比“点一下关闭”麻烦，但能避免很多后续问题。尤其是企业账号，真正耗时间的往往不是关闭动作本身，而是资源、权限、账务、数据之间的交叉依赖。

不建议直接关闭的几种情况

有些账号看似不用了，但不适合立刻关闭。

比如账号里还有生产域名解析，或者还有客户项目的数据备份。再比如这个账号被当作日志归档账号使用，其他业务账号还在往里面写 CloudTrail、S3 日志或监控数据。还有一种情况是 Terraform 后端、镜像仓库、制品仓库仍然在这个账号里，关闭后会影响发布流程。

如果你不确定账号是否仍被依赖，可以先做“冻结使用”：

• 禁止新建资源；
• 停止非必要服务；
• 限制 IAM 权限；
• 保留账单观察一段时间；
• 通知相关团队确认是否还有依赖。

确认没有异常后，再走正式关闭流程，会更稳。

最后再说一句

AWS账号关闭不是一个单纯的控制台操作，更像一次小型下线流程。资源、数据、权限、账单、DNS、CI/CD，每一项都可能影响后续排查。

如果只是个人测试账号，重点是清理资源和保存必要账单。
如果是企业账号，建议把 AWS关停资源、数据备份、财务确认和账号关闭拆成几个明确步骤，最好留有记录。

真正执行 AWS账号注销 前，别急着点关闭。先把资源清干净，把账单和依赖看明白，再处理账号本身，这样后面少很多麻烦。