AWS Account Unban AWS EC2 Instance Creation Failure Troubleshooting

1. Why EC2 Instance Creation Fails

EC2 实例创建失败并不总是“坏了”。更多时候，它是某一环节的校验没有通过：镜像没法用、子网或安全组不匹配、IAM 权限不足、配额用尽、网络路由不通、KMS 密钥无法解密，甚至是你请求的参数组合彼此冲突。问题通常出现在 Launch Instance 的早期校验阶段，也可能在资源真正创建到一半时才暴露。

AWS Account Unban 要把故障排干净，核心思路是：先读懂失败信息，再用最小步骤复现，最后把可能性按优先级缩小范围。下面这篇文章会按“从看到错误到定位根因”的顺序，把常见原因、检查方法和修复动作讲清楚。你不需要猜测，只要按清单走就能快速收敛。

2. Start With the Exact Error Message

很多人第一次排查会直接更换 AMI 或换实例类型，但其实你应该先确认失败信息的精确文本。AWS 控制台通常会给出错误码或原因，例如权限问题、配额不足、无效参数、无法访问子网、磁盘加密相关失败等。

2.1 Where to Find the Details

AWS Account Unban 你可以在以下位置找到更完整的错误信息：

• EC2 控制台：Launch 实例失败后的提示框或事件详情
• 实例创建日志或失败事件（如果你是用自动化/脚本发起，也可能在 CloudTrail 或执行日志里出现）
• CloudTrail：看是否因为 AccessDenied 或某个动作失败而中止

2.2 Don’t Ignore the Error Code

控制台的文字可能很长，但错误码（例如 UnauthorizedOperation、InsufficientInstanceCapacity、InvalidParameterValue）往往能直接把范围缩到很小。你只要先把错误码记下来，再对照下面的排查主题，就能避免在错误方向上花时间。

3. Check Account Limits and Quotas (The Quietest Killer)

最常见的失败之一是配额不足。AWS 会限制每个账户在某个区域可创建的资源数量，例如按实例类型、按 EBS 卷数量、按弹性 IP 数量、按弹性网卡数等。配额耗尽时，创建会失败。

3.1 Verify Region and Service Limits

首先确认你是在正确的区域发起创建。配额通常也是区域级别的。如果你最近迁移到新区域，配额可能更紧。

• AWS Account Unban 到 AWS Service Quotas 查看 EC2 相关限制
• 对照失败信息里提到的资源维度：例如 Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) 或 EBS 相关

3.2 Common Quota Targets

以下项目经常导致创建失败：

• 按实例数/按实例类型的 On-Demand 配额
• AWS Account Unban EBS 卷数量或存储总量不足
• 弹性 IP 配额（如果你尝试自动关联）
• 弹性网卡（ENI）配额（例如你指定了多个网络接口）

解决办法通常是两种：释放已占用资源，或申请提高配额。申请时要明确区域、资源类型和预期规模。

4. IAM Permissions: When You Can’t Launch, Even If Everything Looks Correct

如果你的账户或角色没有足够的权限，EC2 创建会在关键步骤上被拦截。你可能看到 UnauthorizedOperation 或类似错误。

4.1 Use CloudTrail to Confirm the Missing Action

去 CloudTrail 查最近一次创建请求对应的事件。你会看到具体被拒绝的 API 动作，例如 ec2:RunInstances、ec2:CreateTags、ec2:CreateNetworkInterface、kms:Decrypt 等。

4.2 Minimum Permissions Checklist

典型的创建流程可能涉及：

• ec2:RunInstances
• ec2:CreateTags（如果你有标签策略）
• ec2:Describe*（控制台通常会调用）
• ec2:AuthorizeSecurityGroupIngress（如果你要自动修改安全组规则）
• kms:Decrypt 或 kms:Encrypt（如果使用加密的 AMI 或 EBS，且密钥受管）

注意：有些权限不是必须，但如果你的配置启用了“加密”“自定义密钥”“自动安全组写入”等功能，就会变成必需。

5. Image and AMI Issues

EC2 启动失败也可能来自 AMI 本身或你对 AMI 的引用方式。常见问题包括：AMI 不存在、没有订阅/没有共享权限、架构不匹配、或使用了不兼容的启动参数。

5.1 Confirm AMI Ownership and Sharing

如果你用的是社区镜像或跨账户共享的 AMI，确保你的账户对该 AMI 有权限。你可以在 AMI 详情中查看 Owner，并确认是否有共享关系。

5.2 Architecture and Instance Type Compatibility

例如你用了 ARM 架构镜像却选择了不支持的实例类型，或者反过来会导致失败。你还需要确认是否使用了对应的启动模式（如以 HVM/内核参数等方式启动的特殊镜像）。通常普通 AMI 不会这么复杂，但自定义镜像就可能踩坑。

6. Networking Configuration: VPC, Subnet, Route, and Security Groups

当你在 VPC 内创建实例时，网络配置往往决定一切。创建失败不一定等到你登录才发现，有时在创建过程中就会报参数无效或资源不可用。

6.1 Subnet Availability and AZ Matching

检查子网所在的可用区是否与实例类型/容量兼容。某些实例类型在某些 AZ 上容量不足，可能表现为创建失败（而不是“启动后不可达”）。

6.2 Security Group and NACL Are Not Always the Creation Block

安全组和 NACL 更多影响的是网络连通性，但在某些自动化或脚本场景下，你可能在创建阶段就尝试写安全组规则，或遇到权限问题（见第 4 节）。此外，若你使用了自定义规则生成方式并触发参数校验失败，也可能导致创建阶段失败。

6.3 Check Source/Destination Parameters

如果你指定了特定网络接口、静态私有 IP、或自定义路由表相关设置，确保：

• 子网内该私有 IP 没被占用
• 你指定的网络接口数量与实例配置匹配
• 你使用的安全组绑定正确的 VPC

7. Storage and Encryption: EBS Volumes and KMS Keys

EBS 配置是创建失败的另一大来源，尤其是你启用了加密并指定了 KMS 密钥。AWS 可能因为密钥无法使用、权限不够、或快照/卷类型与配置冲突而拒绝创建。

7.1 Verify KMS Key Permissions

如果使用客户主密钥（Customer Managed Key），至少要确保执行角色拥有：

• kms:Decrypt（用于从加密快照或加密 AMI 解密）
• kms:CreateGrant（某些流程会需要）
• 正确的 key policy 允许该角色使用

常见错误表现是：实例创建失败但消息指向 KMS。此时不要急着换 AMI，先修复密钥权限。

7.2 Snapshot and Volume Type Compatibility

如果你基于快照或自定义 EBS 参数创建，确保快照存在且区域一致。EBS 快照是区域资源，不要把不同区域的快照 ID 塞进当前区域的创建请求里。

8. Spot Instance and Capacity Constraints

如果你创建的是 Spot 实例，失败原因通常与容量有关。即便配置正确，只要 Spot 市场在该时间点和该区域可用容量不足，仍可能失败或频繁中断。

8.1 Understand “Insufficient Capacity”

当你看到类似容量不足的错误码，说明不是权限或参数问题，而是 AWS 当下在该维度上没有足够供给。解决思路通常是：

• 更换实例类型或更换可用区
• AWS Account Unban 调整网络/启动方式是否会限制容量（例如过于细的限制条件）
• 增加最大价或使用不同的中断处理策略（Spot diversification）

9. Parameter Validation and User Data Pitfalls

有些失败并不是“外部资源不可用”，而是你输入的参数不符合格式或逻辑。控制台可能在你点击 Launch 后返回 InvalidParameterValue。

9.1 Validate Security Group IDs, Subnet IDs, and Key Pair

请确认这些 ID 都来自同一个区域与同一套 VPC：

• AWS Account Unban Security Group ID
• AWS Account Unban Subnet ID
• EC2 Key Pair 名称（用于 SSH 登录）

特别是你在不同环境复制过配置，容易出现跨区域 ID 混用。

9.2 User Data 不是创建的全部，但会影响后续

User Data 通常不会直接导致“实例创建失败”，但在一些严格的自动化流程里，你可能会把某些依赖（例如下载脚本需要访问内网或需要特定凭证）写进启动逻辑，导致实例启动后表现异常。即便如此，若你看到的是明确的“创建失败”而不是“启动失败”，还是优先回到前面几类根因。

10. A Practical Troubleshooting Workflow

为了避免你在故障现场来回跳，我建议用下面这个顺序。它能最大化减少试错。

Step 1: 记录错误码与完整错误文本

把错误码抄下来，包括是否提到了权限、容量、KMS、参数无效、配额等关键词。

Step 2: 确认区域、VPC、子网与安全组属于同一体系

区域错误最常见：资源 ID 查错区域会导致参数校验失败。先排掉这个最基础的问题。

Step 3: 检查配额（Quota）与容量（Capacity）

AWS Account Unban 如果错误涉及额度不足或实例类型容量问题，直接去配额页面和容量提示里核对。不要先动 IAM 或 AMI。

Step 4: 用 CloudTrail 找到被拒绝的 API 动作

权限不足一定要对着日志修，而不是靠经验猜策略。

Step 5: 对照 AMI/快照/加密配置

如果涉及 KMS 或加密快照，优先修 KMS key policy 与角色权限。若涉及快照 ID，确认区域与快照类型。

Step 6: 最后才做“替换验证”

例如换一个更通用的 AMI、换子网到同一 VPC 的另一个可用区、或用临时 security group 测试。替换验证能帮助你确认问题是否来自特定组件，但别在前面步骤没排查完之前就大量替换。

11. Example Scenarios and What to Do Next

Scenario A: Error Mentions KMS

表现：创建失败信息指向 KMS、Decrypt、AccessDenied。

下一步：

• 确认 AMI/EBS 使用的是否为客户托管密钥
• 检查角色是否有 kms:Decrypt 权限
• 检查 key policy 是否允许该角色所在的账户和条件

Scenario B: Error Mentions Instance Capacity

表现：错误码像 InsufficientInstanceCapacity 或类似容量不足描述。

下一步：

• 尝试不同可用区
• 更换实例类型到同一系列的其它规格
• 如果是 Spot，检查最大价与中断策略

Scenario C: Error Mentions UnauthorizedOperation

表现：CloudTrail 中有 ec2:RunInstances 或 kms:Decrypt 的拒绝。

下一步：

• 用 CloudTrail 确认明确缺失的动作与资源
• 补齐 IAM 策略与资源级别条件（例如限制 tag、限制 VPC 等）

Scenario D: Error Mentions InvalidParameterValue

表现：参数校验失败，常见于跨区域资源 ID 或配置冲突。

下一步：

• 逐个核对 VPC、Subnet、Security Group、Key Pair 是否同区域
• 检查用户数据和网络接口参数是否存在冲突
• 尽量用控制台默认值做对照测试，缩小是哪一个参数出问题

12. Preventing Repeated Failures

你把问题排出来之后，最好做一些“预防性工程”，减少下次又卡在同一个点。

12.1 Standardize Configuration

把关键参数（VPC、子网、安全组、KMS key、AMI 来源）做成固定的模板变量，并在发布时做校验。

12.2 Add Pre-Checks in Automation

如果你用脚本或基础设施即代码来创建实例，建议在真正运行前加入以下检查：

• 确认区域与资源 ID 的一致性
• 确认目标实例类型的配额余量或至少能捕获配额不足的错误码
• 对 KMS key 做权限探测或校验（避免跑到创建阶段才失败）

12.3 Monitor and Archive Error Context

把每次失败的错误码、发起时间、区域、VPC、AMI、以及 CloudTrail 的失败事件归档。这样下一次你就不必从零开始理解新错误，也更容易发现模式。

13. When to Escalate to AWS Support

如果你已经按本文流程做完，仍然遇到模糊错误或大量失败，建议收集足够的上下文再联系支持。准备包括：

• 实例创建请求的时间、区域
• 完整错误信息与错误码
• 相关 CloudTrail 事件（尤其是失败的那条）
• 涉及的 AMI、快照、KMS key 的 ID
• 网络配置摘要：VPC、子网、相关安全组

有了这些，支持团队更容易快速定位。

14. Quick Checklist Summary

最后给你一个紧凑清单，方便你在现场直接对照：

• 先读错误码：权限、配额、容量、KMS、参数校验到底是哪类？
• AWS Account Unban 确认区域一致：AMI、快照、子网、安全组、密钥是否都在同一区域/同体系？
• 检查配额：实例类型、EBS、ENI、弹性 IP 等是否耗尽？
• 查 CloudTrail：到底缺了哪个 ec2:* 或 kms:* 动作？
• 检查加密：KMS key policy 与角色权限是否允许 Decrypt？
• 检查容量：尤其是 Spot 或特定实例类型在目标 AZ 是否缺供？
• 最后才做替换验证：换 AMI/子网/安全组进行对照，但要控制变量。

只要你把“错误信息—资源体系—权限与配额—网络与存储”这条链路走通，EC2 实例创建失败就会从“难以捉摸”变成“可定位、可修复、可复用的流程”。