AWS国际版注册 AWS t4g/t3 性能实测：入门爆款怎么选？

这篇文章写给准备上 EC2 入门实例、却在 t4g（ARM）和 t3（x86）之间犹豫的团队。与其看参数，不如看决策关键：能不能在你业务场景稳住性能、成本是不是可控、账号和支付能否顺利通过风控。

先说结论（基于实测）

• AWS国际版注册 Web API（Node.js/Go）和轻量 Java 服务：t4g.medium 相比 t3.medium 吞吐提升约 25%-40%，按需单价低 15%-20%，综合 TCO 更低。
• 脚本构建、压缩加解密、小型并发任务：t4g 优势明显（多核短突发更稳），前提是依赖库为 arm64 可用。
• 老旧 x86 二进制/商业软件、特定驱动或 SSE 优化组件：优先 t3，省迁移时间。
• 长期满载或 CPU 常年>60%：T 系列都不合适，选 c6g/c6i 这类稳定算力。否则 Unlimited 会给你补一张“隐形账单”。

测试设置与场景描述

• 区域：ap-southeast-1（新加坡），VPC 标准网络，置于同一可用区。
• 实例：t4g.medium（2 vCPU/4GB），t3.medium（2 vCPU/4GB），均为默认 Unlimited。
• 系统：Amazon Linux 2023（aarch64 与 x86_64 各自 AMI），内核 6.x。
• 磁盘：gp3 40GB（3000 IOPS/125 MB/s），避免存储瓶颈干扰。
• 测试工具与负载：
  • HTTP 吞吐：wrk（512 并发、60s），Node.js 快速路由与 gzip 动态响应。
  • Java：Spring Boot 简单接口（JIT 预热 2 分钟）。
  • 计算与压缩：7zip 基准、小文件 gzip 循环。
  • 网络：iperf3 实测实例间吞吐。

说明：以下数字为多轮取中位数，仅作决策参考，实际会随 AMI、内核、邻居噪声和区域略有波动。

核心结果速览（节选）

场景	t3.medium	t4g.medium	差异	备注
Node.js API QPS（p95<50ms）	~11.5k	~15.2k	+32%	同一代码与依赖
Spring Boot QPS（p95<80ms）	~3.9k	~5.0k	+28%	G1 GC，JDK 17 Temurin
7zip CPU 基准（MIPS 合计）	~6200	~8400	+35%	多线程
小文件 gzip（MB/s）	~145	~195	+34%	单线程
实例间网络吞吐	~3.7 Gbps	~4.1 Gbps	+10%	同 AZ，峰值
CPU Credit 用尽后 QPS	~0.4× 下降	~0.5× 下降	t4g 稳定些	Unlimited 产生额外费用

成本对比：不止看小时单价

• 按需单价（以 us-east-1 为例，实际以官网为准）：
  • t4g.medium ≈ $0.0336/小时
  • t3.medium ≈ $0.0416/小时
  • 差异约 19% 折扣，且 t4g 性能更强，单位性能成本优势进一步放大。
• Unlimited 突发费用：
  • t3 多数区域为 ~$0.05/超额 vCPU-小时
  • t4g 多数区域为 ~$0.04/超额 vCPU-小时
  • 如果接口被压爆、CPU 长时间高位，突发费可能比小时费还高。建议稳定负载切换到 C/M 系。
• Spot 价格：
  • t4g Spot 在部分区域容量一般，波动时会回收；t3 Spot 供给更成熟，价格不一定更低，但波动更可预期。
  • 做无状态 Web 用 Spot 时，t3 的中断可预测性通常稍好；t4g 需验证容量稳定性。
• Savings Plans/预留：
  • 计算型 Savings Plans 不区分 x86/ARM，t4g 与 t3 都可覆盖。按 1-3 年承诺，普遍可再降 20%-50%。
  • 有稳定日常负载，优先考虑 Savings Plans 而非 RI，灵活性更好。

“能不能用”的关键限制

• 架构兼容：
  • t4g 是 arm64。Docker 镜像、语言运行时、原生依赖要有 arm64 版本。
  • 常见坑：老旧 Python 轮子、Node-gyp 原生模块、商业探针/Agent 仅提供 x86。
  • 应对：容器尽量选官方 multi-arch 镜像（-slim/-alpine 留意 musl 差异），提前跑 CI 验证 arm64。
• Licensing：
  • 部分商业软件按 CPU 架构授予授权或仅提供 x86 包，迁移前确认许可条款。
• 突发模型：
  • 新账号或冷启动阶段，Credits 未积累时易触发限速；建议压测前先“预热”。
  • 长时间跑编解码、构建等重 CPU 任务会吃光 Credits，性能跳水且出账超额费。

地区差异与容量体验

• ap-east-1（香港）：t4g 容量阶段性偏紧，高峰期更容易出现启动失败或排队；t3 较为稳定。
• ap-south-1（孟买）：t4g Spot 中断频次高于 t3，做批处理需加队列缓冲时间。
• us-east-1（弗吉尼亚）：两者都好用，配额申请快，测试/生产都建议在此先做兼容性验证。
• 新开账户在少量可用区容易遭遇“容量不可用”，尽量预留多个 AZ 的子网以做回退。

选型决策：三步走

1. 确认依赖：容器/运行时/Agent 是否有 arm64 版本；如需改造超过 1 人日，先上 t3 保业务。
2. 确认负载：CPU 峰值多久一次、是否能平滑；若峰值持续 10 分钟以上且日均高，考虑 C 系列。
3. 确认区域：香港/东京若 t4g 容量不稳，先在新加坡/弗吉尼亚做兼容性验证后再迁回。

账号开通与购买避坑

• 注册邮箱与资料：
  • 建议使用企业域名邮箱注册，账户主体与信用卡持卡人信息一致，地址使用拉丁字符。
  • 手机号需可接收国际短信/语音，注册过程会校验。
• 身份与风控：
  • 全球站不需要中国内地“实名认证”，但会做电话/SMS 验证与信用卡$1预授权。
  • 新号常见风控：刚绑卡就创建 EC2 被拒；解决方式是先开通免费层服务、完善账单抬头、等待后台审核数小时。
• 不要采购灰色账户：
  • 二手号/代充账号触发风控概率高，EC2/SES/Route53 批量封禁后的资产找回成本极高。

支付方式与差异

• 优先：双币信用卡（Visa/Master/AmEx），账单地址与账户地址一致。
• 可用但易触发风控：虚拟卡、预付卡、礼品卡。拒付/更换 BIN 后可能要求补充资料。
• AWS国际版注册 借记卡成功率因发卡行风控而异，特别是跨境 3D 验证不稳定时会失败。
• 不可当“余额充值”：AWS 全球站默认后付费，每月扣款。想预付，可通过：
  • AWS Credits（促销码/合作伙伴），按月抵扣。
  • 和经销商签约，月结或预付打款后代付账单。

续费与配额

• 按需实例无“续费”，只要账单正常自动持续运行。
• Reserved Instances/Savings Plans 到期后不自动续，需手动或设定续签策略。
• 新号 EC2 配额通常很低（总 vCPU 限额、每族限额）。要提前提交配额申请，理由简明、附上域名/架构草图，通常 1-3 个工作日批复。

风控审核与典型报错

• Charge failure/卡验证失败：
  • 检查卡状态、跨境交易是否打开、账单地址是否与发卡行一致。
  • 多次失败会冻结创建能力，需等 24 小时或工单解释用途。
• Account verification pending：
  • 新号需要时间，期间尽量不要批量创建实例或使用高风险服务（如大量弹性 IP）。
• Insufficient capacity/OptInRequired：
  • 换 AZ、换实例代数；ap-east-1 首用需要先在控制台开通区域使用权。

实际案例：两类团队的不同路径

• 跨境电商小团队（PHP/Node）：
  • 初期选 t3.small，原因是历史镜像只有 x86。两周内完成容器镜像多架构构建，切 t4g.medium。
  • 结果：QPS 提升 30% 左右，成本下降约 18%；Unlimited 超费从月均 $28 降到 $9（同样流量）。
• SaaS 初创（Java+Agent）：
  • 接入第三方 APM 仅 x86 授权，迁移阻力大。上线期用 t3.medium+1 年期 Savings Plans，稳定后将业务层改造为 arm64，保留边车与 APM 在 t3.small。
  • 结果：主链路迁移后每月省约 22%，APM 侧不改造、风控风险低。

AWS国际版注册 落地操作清单（按阶段）

• 上线前：
  • 准备 multi-arch 镜像（用 buildx），确保 aarch64 测过 e2e。
  • 设置 Auto Scaling 组，跨 2 个 AZ，健康检查 30s 以内。
  • 将 T 系列改为 Standard 模式做压测，验证突发耗尽后的极限。
• 上线时：
  • 先灰度 20% 流量到 t4g，对比 p95/p99 与错误率。
  • CloudWatch 建立两个告警：CPUCreditBalance<100、CPUSurplusCreditsCharged>0。
• 上线后：
  • 统计 7 天 CPU 利用率中位数与 95 分位：超过 40%/60% 的，考虑换 C/M 系列与 Savings Plans。
  • Spot 使用 SIR（中断通知）与最少 N 台 On-Demand 保底，避免全房间黑。

常见问题 FAQ

• Q：我的 Node/Go 服务在 t4g 上跑不起来？
  A：基础镜像换为 arm64 版本，第三方二进制依赖替换为跨架构编译版；CI 用 buildx 同步产出 amd64/arm64。
• AWS国际版注册 Q：Unlimited 要不要关？
  A：压测/构建等短时任务可关（Standard）避免额外计费；线上建议开 Unlimited，但配合 Surplus 告警，一旦频繁触发就换实例族。
• Q：t4g 和 t3 谁更省钱？
  A：相同配置多数场景 t4g 每小时更便宜且性能更高；但如果你的软件栈只能 x86，那迁移成本也要算进总成本。
• Q：新账号起不来 t4g？
  A：先在 us-east-1 开小规格测试，提交配额工单；同时在 2-3 个 AZ 预建子网以便切换。
• Q：能否混用？
  A：可以。常见做法是业务层 t4g，依赖 x86 的边车/代理/采集器放 t3，分层部署。

决策建议（简版）

• 你的容器/依赖已支持 arm64 → 直接上 t4g.small/medium，按需起步，稳定后上 Savings Plans。
• 依赖不确定 → 先上 t3.small 做功能发布，CI 同步改造 multi-arch，2 周内评估切换窗口。
• CPU 长期高位 → 放弃 T 系列，转 c6g/c6i，别烧 Unlimited 费用。
• 区域容量紧张 → 先在 us-east-1 验证与打包，后回迁目标区域。

最后的落地核对

• 账号侧：企业信息完整、卡 BIN 与地址匹配、已通过手机验证、配额工单已提交。
• 成本侧：设置预算与告警，Unlimited 费用单独监控，准备 Savings Plans 评估。
• AWS国际版注册 稳定性：多 AZ、健康检查、容量不够时的回退策略（t4g→t3 或 C 系）。