在 AWS 上创建 EC2 实例时遇到配额相关报错，很多人的第一反应是去提交配额提升申请。但实际上，AWS 的 EC2 配额报错分为两种完全不同的情况，解决方法也截然不同。分清楚这两种报错，是解决问题最重要的第一步。
两种报错的本质差别
VcpuLimitExceeded 的完整报错通常是：
You have requested more vCPU capacity than your current vCPU limit of X allows
for the instance bucket that the specified instance type belongs to.
这是账号层面的配额限制。AWS 为每个账号在每个区域设置了可使用的 vCPU 上限，当你请求的实例所需的 vCPU 数量超出账号的当前配额时，触发这个报错。解决方法是通过 Service Quotas 控制台提交配额提升申请。
InsufficientInstanceCapacity 的完整报错通常是：
We currently do not have sufficient capacity in the Availability Zone you requested.
Please try again with a reduced instance count or alternative Availability Zone.
这是 AWS 侧的容量问题，和你的账号配额完全无关。即使你的配额充足，也可能因为特定可用区的某类实例物理资源暂时耗尽而无法创建。解决方法不是提交配额申请，而是换可用区、换实例类型或拆分请求。
这两种报错经常被混淆，根本原因是”配额”和”容量”这两个词在日常使用中语义接近，但在 AWS 体系中指向完全不同的问题层面。以下分别说明两种情况的处理方式。
VcpuLimitExceeded：账号配额不足的处理
理解 EC2 配额的结构
AWS EC2 的 vCPU 配额按两个维度独立管理：区域和购买类型。
每个区域有独立的配额，us-east-1 的配额提升不影响 ap-east-1。如果你在香港节点遇到配额不足，需要单独在 ap-east-1 提交申请，不能跨区共用。
购买类型同样独立：按需实例（On-Demand）和竞价实例（Spot）是两套完全独立的配额体系。一个非常常见的误操作是：申请了 G 实例族的 Spot 配额，但尝试创建的是按需实例，结果仍然报 VcpuLimitExceeded，因为 On-Demand G 实例的配额还是 0。
AWS 新账号的默认配额如下：
| 实例族 | 默认 On-Demand 配额 | 默认 Spot 配额 |
| Standard（A/C/D/H/I/M/R/T/Z） | 32 vCPU | 需单独申请 |
| G 和 VT（GPU） | 0 vCPU | 0 vCPU |
| P 系列（GPU） | 0 vCPU | 0 vCPU |
| F 实例 | 0 vCPU | 0 vCPU |
| Inf 实例 | 0 vCPU | 0 vCPU |
所有 GPU 实例在新账号下的默认配额均为零，不提交申请就无法创建任何 GPU 实例。这是 AI 训练和推理业务在新账号上遇到的最高频问题。
查看当前配额
在 AWS 控制台搜索「Service Quotas」，进入后选择「AWS 服务」→ 搜索「Amazon EC2」→ 进入 EC2 配额列表。
找到对应的配额项，查看「已使用量」和「配额值」：
# 用 CLI 查看 Standard 实例族的 On-Demand 配额
aws service-quotas get-service-quota \
–service-code ec2 \
–quota-code L-1216C47A \
–region ap-east-1
# 查看 G 和 VT 实例族的 On-Demand 配额
aws service-quotas get-service-quota \
–service-code ec2 \
–quota-code L-DB2E81BA \
–region ap-east-1
常用配额 Code：
- Standard On-Demand：L-1216C47A
- G 和 VT On-Demand：L-DB2E81BA
- P On-Demand：L-417A185B
- Standard Spot：L-34B43A08
提交配额提升申请
在 Service Quotas 控制台找到目标配额后，点击「申请账户级别的配额增加」，填写需要的 vCPU 数量和申请原因。
申请的 vCPU 数量应该按以下方式计算：已在运行的该实例族 vCPU 总数 + 计划新增的实例 vCPU 数 + 10–30% 的缓冲量。例如，计划运行 4 台 g4dn.xlarge（每台 4 vCPU），则需要申请至少 16 vCPU，建议申请 20–24 vCPU 留出余量。
用 CLI 提交配额申请：
aws service-quotas request-service-quota-increase \
–service-code ec2 \
–quota-code L-DB2E81BA \
–desired-value 32 \
–region ap-east-1
申请提交后通过以下命令查询审批状态：
aws service-quotas get-requested-service-quota-change \
–requested-quota-change-id [申请返回的 ID]
标准实例族的配额申请通常在 24–72 小时内审批完成。GPU 实例族（G、P）的审批时间更长，可能需要 3–7 个工作日，且新账号或消费历史很少的账号审批通过率明显低于有稳定消费记录的账号。
申请更容易通过的写法
配额申请的「申请原因」栏填写质量直接影响审批速度和通过率。以下几个要点值得注意：
说明具体的业务用途而不是模糊描述。「用于 AI 模型训练」比「用于计算任务」更容易通过，「部署电商应用后端，预计高峰并发 1,000 个连接」比「跑 Web 服务」更有说服力。
给出明确的时间节点。「计划在 2026 年 8 月 15 日前完成部署，需要在此之前获得配额」比「近期需要」更清晰。
如果是 GPU 实例，说明用于训练还是推理，模型规模大致是什么量级，预计训练时长。这类信息帮助 AWS 判断请求的合理性。
InsufficientInstanceCapacity：容量问题的处理
遇到 InsufficientInstanceCapacity 时，说明你的账号配额充足，但 AWS 在你指定的可用区暂时没有足够的物理资源来满足这个请求。这类问题通常是临时性的，以下几种方法按优先级排列。
等待后重试。 AWS 的容量分配在持续变化，几分钟后重试往往就能成功。如果不是紧急部署，等待是最简单的解决方案。
不指定可用区，让 AWS 自动选择。 创建实例时删除可用区参数，AWS 会在你所在区域内找到有空闲容量的可用区自动分配：
# 不指定 –placement Availability Zone，只指定 region
aws ec2 run-instances \
–image-id ami-0abcdef1234567890 \
–instance-type m5.xlarge \
–count 1 \
–subnet-id subnet-xxx # 如果在非默认 VPC，选其他 AZ 的子网
拆分大批量请求。 如果一次性请求 20 台实例出现容量不足，尝试分 4 次每次请求 5 台，分散到不同可用区，成功率明显更高：
import boto3
import time
from botocore.exceptions import ClientError
ec2 = boto3.client(‘ec2′, region_name=’ap-east-1’)
desired_count = 20
batch_size = 5
launched = []
for i in range(0, desired_count, batch_size):
while True:
try:
response = ec2.run_instances(
ImageId=’ami-0abcdef1234567890′,
InstanceType=’m5.xlarge’,
MinCount=batch_size,
MaxCount=batch_size
# 不指定 SubnetId，让 AWS 自动选可用区
)
launched.extend([inst[‘InstanceId’]
for inst in response[‘Instances’]])
print(f”批次 {i // batch_size + 1} 启动成功”)
break
except ClientError as e:
if e.response[‘Error’][‘Code’] == ‘InsufficientInstanceCapacity’:
print(f”容量不足，30 秒后重试…”)
time.sleep(30)
else:
raise
print(f”共启动 {len(launched)} 台实例”)
换用相近的实例类型。 m5.xlarge 容量不足时，m5a.xlarge、m6i.xlarge 或 m6a.xlarge 可能有充足资源，且规格接近，启动后可以根据实际需要再调整实例类型。关于各实例族的性能和价格差异，可以参考 AWS EC2 实例类型 选择指南。
提前预留按需容量（On-Demand Capacity Reservations）。 对于有明确上线时间节点的重要业务，可以提前购买指定可用区、指定实例类型的容量预留，预留后该实例类型的容量始终可用，不受临时的容量不足影响。按需容量预留按实际预留时长计费，不管是否有实例在使用。
新账号配额低的原因与高权重账号
AWS 为新账号设置偏保守的默认配额，主要原因是防止欺诈性使用——恶意用户批量注册账号大规模挖矿或发送垃圾邮件，低默认配额让这类行为的规模受限。
这个机制对正常业务用户的影响是：新账号创建后 GPU 配额为零，申请提升需要等待审批，而审批速度和通过率与账号的消费历史直接相关。没有任何消费记录的全新账号，GPU 配额申请可能需要更长时间，甚至需要多次申请或联系 AWS 支持工程师介入。有稳定月度消费（通常 $200 以上）的账号，配额申请的通过率明显更高，审批时间也更短。
这是通过代理渠道获取账号的实际价值之一。通过 AWS 代理商 渠道开通的账号属于高权重高配额账号，初始配额明显高于自助注册的新账号，GPU 实例配额申请的通过率更高，审批周期更短，适合有明确的 GPU 或高规格实例需求的团队。
如果当前账号的配额申请反复被拒、审批时间过长影响项目进度，通过 亚马逊云账号出售 渠道获取高权重账号是更直接的解决方案，1 分钟极速交付，免实名免绑卡，账号初始配额更宽松，可以直接用于正式业务部署。
配额申请需要的 IAM 权限
如果你使用的是 IAM 用户或角色而不是 root 账号，需要确认当前身份有查看和申请配额的权限。最小权限策略应包含：
{
“Version”: “2012-10-17”,
“Statement”: [
{
“Effect”: “Allow”,
“Action”: [
“servicequotas:GetServiceQuota”,
“servicequotas:GetRequestedServiceQuotaChange”,
“servicequotas:RequestServiceQuotaIncrease”,
“servicequotas:ListServiceQuotas”
],
“Resource”: “*”
},
{
“Effect”: “Allow”,
“Action”: [
“ec2:DescribeInstanceTypeOfferings”,
“ec2:DescribeInstanceTypes”
],
“Resource”: “*”
}
]
}
关于 IAM 权限策略的创建和授予方式，可以参考 AWS IAM 权限管理教程。
常见误判场景整理
申请了 Spot 配额但创建的是 On-Demand 实例。 Spot 和 On-Demand 是两套独立配额，两者需要分别申请。申请配额时要明确选择正确的购买类型。
在一个区域申请了配额，但在另一个区域创建实例。 配额是区域级的，ap-east-1（香港）的配额和 ap-southeast-1（新加坡）完全独立，需要分别申请。
配额显示 32 vCPU，但 t3.micro 创建还是失败。 t3.micro 使用 2 vCPU，账号现有 30 个 Standard 实例在运行，已经用完 32 vCPU 配额，新实例无法创建。需要先终止部分实例或申请更高配额。
创建 g5.xlarge 失败，但 g4dn.xlarge 可以创建。 两者虽然都是 G 实例族，但共享同一个 G 和 VT 的 vCPU 配额池。g5.xlarge 需要 4 vCPU，如果当前剩余 G 实例配额不足 4，则无法创建，但已有实例没有受影响。
