AWS 账号被盗，很多时候并不是简单的“登录不上”。更常见的情况其实是：账单突然飙升、某些陌生区域冒出 EC2 实例、CloudTrail 里出现自己没见过的 API 调用，或者 IAM 用户、访问密钥被莫名其妙创建出来。

因为 AWS 是按量计费的，只要攻击者拿到权限，就可能用你的账号挖矿、群发邮件、滥用计算资源。费用往往不是慢慢涨，而是在很短时间内迅速堆起来。

如果你正在查“AWS账号被盗怎么办”或者“AWS账号恢复”，先别慌，也不要只做一件事——改密码。改密码当然重要，但远远不够。更稳妥的思路应该是：先止损，再查证据，然后恢复账号，最后做安全加固。下面这份内容按照实际排查顺序整理，个人开发者、中小企业运维、云账号管理员都可以参考。

一、先确认：你的 AWS 账号是不是真的有异常

AWS 账号被盗，不一定会表现为无法登录。有些攻击者反而会尽量不惊动你，让账号看起来还能正常使用，只是在后台偷偷创建资源。所以第一步，还是要先判断有没有未经授权的操作。

可以从下面几个方向重点检查。

先看账单有没有异常增长。
进入 AWS Billing and Cost Management，看看本月费用、按服务拆分的费用，以及按区域拆分的费用。如果发现自己从没用过的服务或区域突然产生费用，比如陌生区域里的 EC2、EBS、NAT Gateway、SageMaker、Lightsail 等，就要特别警惕了。

再看陌生区域有没有资源。
AWS 是多区域架构，攻击者经常会选择你平时不看的区域下手。建议把所有已启用区域都过一遍，尤其是 EC2 实例、EBS 卷、弹性 IP、RDS、Lambda、IAM、CloudFormation 这些常见资源。

IAM 用户、角色和访问密钥也要重点查。
如果你看到不认识的 IAM 用户、不明访问密钥、权限特别大的策略绑定，或者 root 账号下面居然存在访问密钥，这些都可能说明凭证已经泄露。

CloudTrail 是非常关键的线索。
排查 AWS 账号是否被盗，CloudTrail 基本绕不开。可以重点关注这些敏感操作：CreateUser、CreateAccessKey、RunInstances、AuthorizeSecurityGroupIngress、AttachUserPolicy、UpdateLoginProfile、CreateRole 等。如果这些操作不是你或团队成员执行的，风险就很高。

安全组和网络配置也别忽略。
比如安全组突然开放了 0.0.0.0/0 的 SSH、RDP、数据库端口，或者 VPC、路由、NAT 配置被改过，都应该视为潜在异常。

只要你确认出现了非本人、非团队授权的资源、API 调用或费用，基本就可以按照“AWS 账号疑似被盗”来处理了。

二、第一时间止损：先别让费用继续扩大

如果账号还能登录，优先级不是慢慢研究“到底怎么被盗的”，而是先阻断攻击者继续操作。原因很简单：AWS 按量计费，拖得越久，损失越大。

1. 立刻修改 root 账号密码，并启用 MFA

如果你还能登录 root 账号，第一件事就是修改 root 用户密码，然后开启多因素认证，也就是 MFA。

MFA 建议使用虚拟 MFA 应用，或者硬件安全密钥。不要只依赖邮箱和密码，因为邮箱本身也可能成为攻击入口。

需要提醒的是，root 账号权限最高，平时不应该拿来管理日常资源。它主要用于账单、账户级设置，以及少数必须 root 才能操作的场景。

2. 删除或停用 root 访问密钥

正常情况下，root 账号不应该长期持有访问密钥。如果你在 Security Credentials 里看到 root access key，建议马上停用，然后删除。

很多 AWS 账号被盗事件，本质上不是控制台密码泄露，而是 Access Key 泄露。攻击者拿到密钥后，可以直接通过 API 创建资源，哪怕你修改了控制台密码，也挡不住他们继续调用接口。

3. 轮换所有 IAM 用户的访问密钥

接下来要检查所有 IAM 用户。

不认识的 IAM 用户，先停用访问权限，再确认是否删除；不认识的 Access Key，立即停用；长期没用过的密钥，直接清理；正在业务中使用的密钥，则要生成新密钥，替换到业务配置里，确认服务正常后再删除旧密钥。

这里很关键：不要只改控制台密码。如果攻击者手里拿的是 Access Key，改密码并不能阻止 API 调用。

4. 停止或删除异常资源

确认某些资源不是业务需要后，要尽快停止或删除。常见需要检查的包括：

• 陌生 EC2 实例；
• 不明 EBS 卷和快照；
• 异常弹性 IP；
• 不认识的 Lambda 函数；
• 非授权创建的 RDS、ECS、EKS、SageMaker 等资源；
• 可疑的 CloudFormation Stack。

如果你不确定某个资源是不是业务在用，建议先停止或隔离，再和团队确认。删除之前，最好保留必要的截图、资源 ID、时间线和 CloudTrail 记录，后面和 AWS Support 沟通时会更清楚。

三、如果已经无法登录 AWS 账号，该怎么办

如果你已经登录不了 AWS 账号，就要根据具体情况处理。

1. root 密码被改，或者忘记了

可以先尝试通过 AWS 登录页重置 root 用户密码。前提是你还能访问注册 AWS 账号时使用的邮箱。

如果邮箱也被盗了，事情会麻烦很多。这个时候应该先恢复邮箱控制权，否则 AWS 账号恢复流程会变得更复杂。

2. MFA 设备不可用

如果 root MFA 设备丢失，或者怀疑被攻击者替换，需要按照 AWS 官方流程提交身份验证。一般会涉及账号邮箱、电话、账单信息等验证内容。

这些流程和要求可能会随着 AWS 官方政策调整，所以具体操作还是要以 AWS 官方帮助页面和 Support 表单为准。

3. 账号被暂停或关闭

如果 AWS 因为账单、滥用行为或安全风险暂停了账号，就需要联系 AWS Support 处理。通常你需要先完成身份验证，说明异常情况，清理非授权资源，并按照 AWS 要求完成安全修复。

账号能不能恢复、多久恢复、账单怎么处理，这些都要以 AWS 官方审核结果为准。

如果账号关闭后还想重新打开，也应该尽快联系 AWS Support。AWS 对关闭账号的保留和恢复通常有时间限制，具体仍然要看官方最新说明。

四、怎么向 AWS Support 说明账号被盗

AWS 账号恢复过程中，Support case 写得清不清楚非常重要。不要只写一句“我的账号被盗了，请帮我取消账单”，这样很难推动处理。

更好的方式是把事情说清楚、说具体，并尽量提供可验证的信息。比如可以准备：

• AWS 账号 ID；
• 发现异常的时间；
• 涉及的异常服务和区域；
• 异常资源 ID，比如实例 ID、卷 ID、密钥 ID；
• 账单异常的服务明细；
• 你已经完成的安全措施，比如修改密码、启用 MFA、停用密钥、删除异常资源；
• 你怀疑的泄露原因，比如 Access Key 曾出现在代码仓库、离职员工权限未回收、邮箱被盗等；
• 希望 AWS 协助调查未经授权活动及相关费用。

表达上尽量客观、清晰。例如可以这样写：

我们在某日期发现账号存在未经授权活动，主要表现为某些区域出现非我方创建的 EC2 实例，并产生异常费用。我们已修改 root 密码、启用 MFA、停用可疑访问密钥，并删除异常资源。请协助调查这些活动是否由账号被盗导致，并指导后续账号恢复和账单处理流程。

需要注意的是，AWS 是否减免异常费用，并没有固定承诺。一般会结合账号情况、异常记录、处理是否及时、安全修复是否完成等因素综合判断。你能做的，就是尽快止损、保留证据，并配合 Support 完成调查。

五、重点复盘：AWS 账号最容易从哪里被攻破

很多人只关注“被盗后怎么办”，但真正重要的是找到入口。否则这次处理完了，过几天可能又被入侵。

1. Access Key 泄露到代码仓库

这是非常常见的原因。建议检查 GitHub、GitLab、Gitee、CI/CD 日志、前端代码、镜像仓库和配置文件中，是否出现过这些内容：

• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY
• .env
• credentials
• config
• Terraform state 文件

如果密钥曾经提交到公开仓库，即使后来删除了，也不能当作没发生过。因为它很可能已经被自动扫描工具抓取。正确做法是马上废弃旧密钥，而不是只把代码删掉。

2. IAM 权限给得太大

有些团队为了省事，直接给 IAM 用户绑定 AdministratorAccess。这样做短期看起来方便，但一旦某个密钥泄露，整个账号基本就失守了。

更合理的方式是按照最小权限原则来拆分权限。生产环境、测试环境、账单权限、运维权限，最好分开管理，不要所有事情都用同一个高权限账号处理。

3. root 账号被日常使用

root 账号不适合日常登录，更不适合 API 调用。建议创建独立管理员 IAM 用户，或者使用 IAM Identity Center。root 账号启用强密码和 MFA 后，妥善保管即可，平时尽量不要使用。

4. 邮箱和密码复用

如果 AWS 注册邮箱使用的是弱密码，或者和其他平台共用密码，攻击者可能会先拿到邮箱，再通过邮箱重置 AWS root 密码。

所以邮箱本身也要启用 MFA，并且使用独立的高强度密码。这一点看起来基础，但非常重要。

5. 团队成员权限没有及时回收

员工离职、外包交接、临时测试账号没清理，这些都会留下安全隐患。IAM 用户和访问密钥应该定期审计，长期不用的权限要及时回收。

六、账号恢复后，必须做这些安全加固

AWS 账号恢复，不只是重新登录成功就结束了。真正的目标是确保攻击者不能再次进入。建议按下面这些事项逐项检查：

• root 账号启用 MFA；
• 删除 root 访问密钥；
• 所有 IAM 用户尽量强制使用 MFA；
• 删除未知 IAM 用户、角色和策略；
• 轮换所有 Access Key；
• 检查所有区域的 EC2、EBS、RDS、Lambda、ECS、EKS、Lightsail 等资源；
• 检查安全组是否开放了高危端口；
• 开启并保留 CloudTrail 日志；
• 配置账单告警和预算提醒；
• 使用 IAM Access Analyzer 检查公开访问和跨账号访问；
• 定期审计不活跃用户和密钥；
• 将密钥迁移到 Secrets Manager、Parameter Store，或者安全的 CI/CD 变量管理中。

如果是企业团队，还建议建立一套云账号使用规范。比如谁可以创建密钥，谁可以开通高成本资源，资源命名怎么统一，预算告警由谁接收，异常账单由谁处理。安全不是一次性动作，而是一套持续流程。

七、异常账单能不能减免？要理性看待

很多用户最关心的问题是：AWS 账号被盗后产生的费用，能不能取消？

这个问题需要谨慎看待。AWS Support 通常会对疑似欺诈或未经授权使用进行调查，但是否减免、减免多少、需要提供哪些证明，没有办法提前保证。

账号状态、历史使用记录、你发现和处理的速度、是否完成安全修复，都会影响最终结果。

比较现实的做法是：

• 第一时间停止异常资源，避免费用继续扩大；
• 保留证据和完整时间线；
• 尽快提交 Support case；
• 按 AWS 要求完成账号加固；
• 持续跟进账单和工单状态。

另外，不要轻信“保证消除账单”“百分百解封”“内部渠道直接恢复”这类说法。AWS 账号恢复和费用审核，最终还是以 AWS 官方处理结果为准。

八、NiceCloud 能提供哪些相关协助

NiceCloud 是国际版云服务代理，适合有海外云服务采购、企业充值、开票和基础技术协助需求的用户。

对于 AWS 账号疑似被盗这类问题，账号安全调查、身份验证和最终恢复流程，仍然需要通过 AWS 官方 Support 完成。

在合规边界内，NiceCloud 可以围绕云账号使用提供一些基础协助，比如帮助用户梳理排查思路、理解账单构成、定位常见异常资源、提醒安全加固要点等。至于 AWS 官方政策、账号处置、费用减免和恢复结果，则应以 AWS 官网和 Support 的最新答复为准。

如果你的团队缺少云账号管理经验，也可以在日常使用中提前建立预算提醒、权限分级、密钥管理和账单审计机制。这样即使后续遇到 AWS 账号被盗，也能尽量降低损失和恢复难度。

九、总结：AWS 账号被盗后，按这四步处理

如果你怀疑 AWS 账号被盗，可以按这个顺序来：

第一，确认异常。
检查账单、区域资源、IAM、CloudTrail 和安全组，看看是否存在未经授权的操作。

第二，立即止损。
修改 root 密码，启用 MFA，停用可疑密钥，停止或删除异常资源。

第三，联系官方。
向 AWS Support 提交清晰的证据、时间线，以及你已经完成的修复动作。

第四，恢复并加固。
轮换凭证，落实最小权限，配置账单告警，并建立持续审计机制。

AWS 账号恢复的关键，不在某一个单独操作，而在于快速、完整、可验证地控制风险。发现得越早，止损越及时，后续处理空间通常就越大。

对企业用户来说，最好的恢复方案永远是提前预防：不要让 root 账号裸奔，不要让 Access Key 出现在代码里，也不要让高权限账号长期无人审计。