业务资源瓶颈决定实例类型：计算密集型选c系列，内存受限选r系列，均衡负载选g系列；同配置下e/u/c实例性能差异可达2倍，需按真实瓶颈匹配而非参数堆砌。
看业务主要“吃”哪类资源——CPU、内存、磁盘IO还是网络，就选对应优化的实例类型。
先判断业务负载特征
如果程序频繁做数学运算、视频转码、批量数据处理、实时编译或高并发Web前端（比如Nginx负载高），CPU持续跑满、响应变慢，说明是计算密集型，优先考虑计算型（c系列），比如c9i、c9a，主频高、单核强、算力稳定。
如果数据库查询慢、Redis缓存命中率低、Java应用频繁GC、Elasticsearch搜索卡顿，通常是因为内存不够用，这时候要盯紧内存容量和带宽，选内存型（r系列），如r9i、r9a，vCPU:内存配比可达1:8甚至更高，专为大内存场景设计。
如果业务比较均衡——比如企业官网、OA系统、中小API服务、WordPress站点，既需要一定CPU，也得有够用内存，还不挑网络或磁盘，那就选通用型（g系列），像g9i、g8a，配比通常是1:4，兼容性好，稳定性强，适合大多数生产环境。
别忽略底层差异
同样标着“4核8G”，经济型e实例是共享CPU，通用算力型u2i是独享vCPU，计算型c9i则用的是Intel Granite Rapids处理器+全核睿频3.6GHz。性能差距可能接近2倍，不能只看参数数字。
简单对照建议
- 小程序/轻量官网/开发测试 → 通用算力型 u1/u2i 或 经济型 e（预算极紧时）
- MySQL/Redis/ES/SAP HANA → 内存型 r9i/r9a
- 视频编码/游戏服/高频交易接入层 → 计算型 c9i/c9ae 或 通用型 g8ine（高PPS场景）
- 大数据节点（Hadoop/Spark）→ 大数据型 d系列（带本地NVMe盘）
选型本质是让资源能力贴合真实瓶颈，不是越高配越好，也不是越便宜越合适。
