AWS海外账号 t4g vs M7g vs C7g：Web 高并发极限压测
AWS海外账号 如果你是在搜这个标题，通常不是想看参数表，而是想快速判断：压测要选哪台、账号怎么开、会不会被风控、钱怎么付、最后总成本是不是划算。结论先说在前面：
做长期高并发 Web 压测，优先看 M7g；CPU 明显吃紧、请求链路短且能把算力打满时选 C7g；T4g 只适合低成本预演、流量不稳定或验证业务链路，不适合拿来做“极限”结论。
先说决策：别只看单价，要看压测结果能不能代表真实生产
高并发 Web 场景里，最容易踩的坑不是机器贵，而是压出来的结果不可信。T4g 的典型问题是 CPU credit：前半小时看着很便宜、很能跑，后面一旦信用耗尽，延迟会突然抖上去，压测图像很好看，线上却不是那个曲线。这个结果对“找极限”没有参考价值，反而会误判架构。
M7g 更像是标准答案：适合 Nginx、PHP-FPM、Java Web、Node.js API 这类持续吃 CPU 和内存的业务，压测曲线更稳，适合看真实瓶颈在应用层、数据库还是带宽。C7g 则更适合请求处理路径短、CPU 消耗高的服务，比如接口聚合、签名校验、压缩、加密、规则计算、渲染类工作负载。
| 机型 | 适合场景 | 压测时最常见现象 | 结论 |
|---|---|---|---|
| T4g | 低成本验证、流量波动大、测试环境 | 前期表现不错，后期 CPU credit 耗尽后延迟飙升 | 不建议用来下“极限性能”结论 |
| M7g | Web 主站、接口服务、中高并发常态运行 | 性能更平稳，容易观察数据库、缓存、应用代码瓶颈 | 最适合做压测基线 |
| C7g | CPU 密集型 API、短链路高吞吐、计算型请求 | RPS 更容易拉高，但内存和业务兼容性要先确认 | 适合冲上限，不适合盲目堆配置 |
账号怎么开：别买现成号，风控和回收风险太高
很多人搜“账号购买”，其实是想快点开始压测。但如果你是做 AWS 国际站，最稳的方式永远是自己注册、自己实名、自己绑卡。现成账号看似省时间，实际常见问题是：密码找不回、账单归属不清、历史风控记录继承、某些区域或服务直接被限，后面压测还没开始，账号先出问题。
正常流程建议是：先注册主账号，再完成手机号和邮箱验证，补充真实的个人或企业信息，绑定可扣款的信用卡/借记卡，开启 MFA，最后再去开 EC2、ELB、EIP 这类资源。新号不要一上来就开太多区域、太多实例、太多弹性 IP，这类动作最容易触发人工审核。
实名认证和风控：信息一致比“资料多”更重要
国际云的审核不是看你材料堆得多不多，而是看信息是否一致。姓名、账单地址、卡片持有人、登录地区、手机号归属，尽量保持同一逻辑。常见失败原因不是“资料不全”，而是“信息对不上”。
如果是企业账号，建议提前准备营业执照、公司地址、联系人邮箱和电话。很多人卡在这里，是因为用个人身份注册，却想直接开大规模资源，或者刚注册就切换多个国家/地区登录。对风控来说，这类行为比正常建站更像异常测试。
还有一个实战建议：不要在同一张卡上短时间注册多个新账号，也不要频繁换登录网络环境。对于压测账号来说，稳定登录比“折腾速度”更重要。
支付方式：AWS 和国内云的习惯不一样
如果你习惯了国内云的预充值和余额续费，AWS 的节奏会不太一样。它更偏向按账单扣费，所以你要重点盯的不是“卡里有没有余额”，而是“扣款方式是否可用、账单是否会突然放大”。
实操里建议这样做：
- 用一张长期可用的信用卡或借记卡，不要用临时卡。
- 开通预算告警，别等到月末才发现流量费比实例费还高。
- 压测期间把自动扩容、NAT 出口、负载均衡、数据传输费用一起算进去。
- 如果要跑多天压测，先确认卡片的单笔或日限额，避免中途扣款失败导致实例被停。
AWS海外账号 很多人只盯着实例价格，最后吃亏的是带宽和出站流量。高并发 Web 场景里，静态资源、接口返回、日志、镜像分发都可能把账单抬高，尤其是你在多个区域反复测试时。
三款机器怎么选：按业务形态，不按“谁更强”
1）T4g：适合预演，不适合定结论。 如果你的站点日常流量低，偶尔有活动峰值，T4g 可以用来验证部署、监控、缓存命中率和基础链路。但做高并发极限压测时，它最大的风险就是“跑着跑着掉性能”，测试结果会偏保守或失真。
2）M7g：适合大多数 Web 服务。 如果你是标准前后端分离、Nginx + 应用服务 + Redis 的结构，M7g 往往是最省心的起点。它的稳定性更适合你看清楚瓶颈到底在代码、数据库还是连接池，而不是被 CPU credit 干扰。
3）C7g：适合把 CPU 榨干的场景。 如果你的接口逻辑比较重、并发一高就出现 CPU 满载、压缩和加密占比高，C7g 通常更容易把吞吐做上去。它更像是“冲上限”的机器，但前提是你的程序和依赖都已经适配 ARM 架构。
成本对比：别只算机器单价，要算每 1000 请求成本
真正有用的对比方式不是“每小时多少钱”，而是每 1000 次请求花多少钱。举个常见思路：
- T4g 单价低，但一旦 credit 耗尽，后半程吞吐下降，单位请求成本未必低。
- M7g 通常是综合成本最好算的，适合长时间运行，压测数据也更容易复用到生产。
- C7g 如果能把 CPU 利用率稳定拉高，单位请求成本可能更漂亮，但前提是业务确实吃 CPU。
如果你的业务瓶颈其实在数据库、磁盘或外网出口，继续加大实例规格并不会降本。很多团队压测到最后才发现，真正烧钱的是负载均衡、NAT、日志和出站流量，而不是那台 EC2 本身。
使用限制：ARM 兼容、区域差异、配额是三道门槛
这三台都是 ARM 体系，兼容性先于性能。你要先确认镜像、容器、依赖包、第三方插件能不能跑在 ARM64 上。尤其是老版本 PHP 扩展、闭源二进制、部分监控 Agent、老 JDK 版本，最容易在上线前卡住。
区域差异也很现实。不同区域价格、网络时延、库存、可申请配额都不一样。你做压测如果只是为了国内访问体验，通常会优先考虑离用户近的区域；如果是为了对接海外业务，就别拿一个低时延区域的结果去代表另一地的真实体验。
新账号常见限制还有：vCPU 配额偏低、公共 IP 申请受限、某些实例规格暂时不可开通。解决办法不是硬冲，而是先做小规模验证，再逐步申请提升配额。
常见问题：压测前先把这几个坑排掉
Q：新账号能直接压极限吗？
不建议。先跑小流量，确认账单、配额、镜像和监控都正常，再放大。
Q：为什么同样是 ARM，结果差别这么大？
因为 Web 压测不只看 CPU。数据库、缓存、TLS、日志、网络延迟都会改结果。M7g 和 C7g 的差别，通常要放到真实应用链路里看。
Q：要不要先买最便宜的机器试？
如果只是验证部署，可以；如果目标是找性能上限，T4g 省下来的钱，可能会换来一份没用的压测报告。
Q：续费怎么避免突然中断？
关键不是“充值”，而是保持可扣款方式有效、开启预算提醒、不要让账单超限。压测前最好把扣款和告警都测一遍。
最后给一个实操建议
如果你现在就要开干，建议顺序是：先自注册账号并完成实名与绑卡，再用 M7g 做基线压测，确认瓶颈后用 C7g 冲极限，T4g 只拿来做低成本预演或回归测试。这样拿到的数据更接近真实生产，也更容易控制风控和账单风险。
真正决定“选哪台”的，不是名字，而是你的业务是不是 ARM 兼容、是不是 CPU 密集、是不是要长时间跑、是不是能接受账单波动。把这四件事理清楚，再去压测，结论会比单纯比参数靠谱得多。
