背景
AWS EC2 是 AWS 的弹性计算服务，为广大开发者提供简单便捷弹性的虚拟机，是 AWS 历史最悠久的服务之一（另外一个是 S3），从 2006 年发布至今，已经发展了近 17 年历史。
相信不少刚开始接触 EC2 的朋友都有如下类似的感受：
- AWS EC2 的类型实在是太多了（数百种）！我究竟应该选择哪一种 EC2 机型既能满足业务需求且不超过预算 ？
- EC2 的 CPU 和 Memory 配置一样，是不是代表它们的性能差异也一样 ？
- 采用什么样的 EC2 付费模式才比较划算 ？
回想 EC2 刚开始发布时，只有两种 机型可供选择，而如今则有 781 种，琳琅满目的 EC2 类型必然会让开发者们陷入选择困难症。本文将简单介绍一些 EC2 机型选择的小技巧，目的是为了帮助读者能够更快地选择合适的 EC2 机型。
机型分类和选择
总体分类
尽管 AWS 有数百种 EC2 机型，但其实只有以下几种大的分类： ![]()
- General Purpose：Compute、Memory 和 Networking 资源相对平衡，即 M 系列和 T 系列。绝大多数场景用 General Purpose 就足够了；
- Compute Optimized：计算优化型，适合计算密集型服务，即 C 系列；
- Memory Optimized：内存优化实例旨在为处理大型数据集的工作负载提供快速性能，主要有 R 和 X 系列；
- Accelerated Computing：加速计算实例使用硬件加速器或协处理器来执行功能，例如浮点数计算、图形处理或数据模式匹配，比在 CPU 上运行的软件更高效；
- Storage Optimized：存储优化实例专为需要在本地存储上对非常大的数据集进行高速连续读写访问的工作负载而设计；
- HPC Optimized：这是 AWS 新出一个分类（HPC 系列），主要适用于需要高性能处理的应用程序，例如大型复杂模拟和深度学习工作负载。
一般来说，每一个具体的 EC2 型号都从属于某个带有相应数字序号的 Family，比如以 General Purpose 类型的 M 系列为例：
- M7g / M7i / M7i-flex / M7a
- M6g / M6i / M6in / M6a
- M5 / M5n / M5zn / M5a
- M4
从序号上我们不难看出，M7 是最新一代的产品，而 M4 则是相对比较旧款的型号。序号越大，则说明对应的机型和 CPU 型号也就是越新，同等配置下价格也有可能会更实惠（硬件总是在不断贬值）。
关键参数
从 AWS 一个典型的 EC2 型号介绍，我们可以提取出以下几个关键参数： ![]()
1. EC2 的具体型号 一般以 <family>.<size> 命名，比如 m7g.large / m7g.xlarge 等。对于 EC2 来说，某种型号在全局是唯一的；
2. CPU 和 Memory 大小 即上图中的 vCPU 和 Memory 大小。绝大多数 EC2 机型都是 1:4，即 vCPU 和 Memory 的数量上的比值。比如，当 vCPU 为 1 时，Memory 通常是 4GiB；当 vCPU 为 2 时，Memory 通常是 8GiB，以此类推；
3. 实例存储 EC2 通常可以挂载不同类型的持久化存储盘，主要有以下几种：
-
EBS
EBS 是 AWS 的分布式块存储服务 ，通常也是大多数 EC2 机型默认选择的持久化存储方式。有些机型只能选择使用 EBS。EBS 是与具体 AZ 相绑定，读写延迟当然会比本地 SSD 要差一些，但在大多数场景下也能接受。根据 IOPS 和吞吐量等一些参数的不同，EBS 也有不同的类型，比如：
-
本地存储
某些机型除了支持挂载 EBS 外，同时还支持本地存储，当然，价格上也会更贵一些。一般这类机型的型号上都会 带有 d，比如：m7g.large 是 EBS-Only 的机型，而 m7gd.large 则是带有 1 块 118GiB NVME SSD 本地存储的机型。某些特殊机型还支持容量更大本地 HDD；
4. EBS 带宽 对于一些比较新且有专门的 EBS 优化的 EC2 机型，AWS 都会为其配备专用的 EBS 带宽。这意味着在高数据量吞吐的场景，EBS 优化机型总能享有更好的吞吐而不与本机上的网络带宽有资源竞争；
5. 网络带宽 即 EC2 机型对应的网络带宽。
6. CPU 型号 大多数场景下，我们能看到以下几种厂商的 CPU：
- AWS 自研的基于 ARM 架构的 Graviton 处理器（目前已经到 Graviton 3），比如 M7g 系列；
- Intel x86-64 架构的 CPU；
- AMD x86-64 架构的 CPU；
一般来说，相近配置上价格上是：Intel > AMD > Graviton，性能则刚好反过来。对于一些性能不敏感的通用化场景，用户可以考虑使用 ARM 架构的机型，这样能获得更高性价比。
AWS 是最早尝试将 ARM 架构引入服务器 CPU 领域的云厂商，经过多年的研发，Graviton CPU 已经取得长足的进步，性价比上有很大的竞争优势，估计未来 AWS 会推动越来越多的客户使用 Graviton CPU 机型。
7. 虚拟化技术 不同的 EC2 机型底层使用的虚拟化技术也是不完全相同的，这也导致了一些参数上的差异。比如对于较新的 EC2 机型，一般都采用 Nitro 虚拟化技术。Nitro 是 AWS 最新的虚拟化技术，将很多虚拟化行为都卸载到了硬件上，而软件上则可以做得相对较轻量，从而虚拟化性能会更强，从用户视角感受到则是相同配置下会有更好的性能（因为虚拟化的 Overhead 更低了）。
8. 是否用于机器学习场景 随着 LLM 技术的发展，越来越多的厂商会选择在云端训练自己的模型。如果想在 AWS EC2 使用模型训练，一般会使用 Accelerated Computing 这个大类的机型，比如：
- P 系列和 G 系列机型：这部分使用的是 Nvidia 的 GPU 芯片。在 re:Invent 2023 大会上，Nvidia 与 AWS 开启了更深度的战略合作，AWS 计划使用 Nvidia 最新最强的 GPU 来打造一个专门用于生成式 AI 的算力平台；
- Trn 和 Inf 系列：AWS 除了使用 Nvidia GPU，自己也研发专用于机器学习的芯片，比如用于训练的 Trainium 芯片和模型推理的 Inferentia 芯片。Trn 系列和 Inf 系列的 EC2 机型则分别对应这两种 AWS 自研的机器学习芯片；
Key Takeway
根据我们上文的一些简单介绍（EC2 可以说的内容远不止于此），我们总结了一下小技巧供读者参考：
-
对于大多数 EC2 机型，一般序号越大，CPU 型号越新，性能会越强，价格反而会越便宜，即性价比更高；
-
EC2 通用型中 T 系列相对便宜，并且提供了一种 Burstable CPU 的特性：实例在基线性能下运行会累积 CPU 积分，当遇到基线性能之上的高负载场景时可根据 CPU 积分运行超出基线性能一定时间的能力（费用不变），但随之也带来 T 系列性能不会太高，普遍带宽也低且没有 EBS 优化。因此 T 系列比较适合非性能验证的测试环境；
-
EC2 通用型系列中如果追求性价比，可优先选择 AWS ARM 架构；
-
AWS 官网的 EC2 Pricing 非常难以阅读，推荐使用 Vantage 的 https://ec2instances.info/ 来查阅价格信息（这也是一个开源项目）；
-
对于大多数云用户来说，EC2 的费用一般是其大头支出，这里有几个手段可以尽量减低这方面的开支：
- 充分运用云的弹性：让你的架构尽可能弹性，按需使用算力，这里可使用 AWS 的 Karpenter 或者 Cluster Autoscaler 来让你的 EC2 具备灵活伸缩的能力；
- 使用 Spot 实例：Spot 实例的价格可比 On-Demand 实例便宜 30% 甚至 90%，但是会被抢占，无法长时间稳定运行。AWS 会在抢占前 2 分钟提醒你，然后就进行抢占。Spot 实例如果底层管理得好，非常适合弹性计算且可容忍中断的场景，比如 SkyPilot 项目就是拿不同的云的 Spot 实例进行机器学习训练；
- 优化付费模式：除了技术手段，我们其实还可以通过购买 Saving Plans 等方式来获得比 On-Demand 更低廉的单位使用时间，但缺点就是灵活度降低，比较适用于整体业务架构相对稳定的场景。
总结
如何高效选择和使用 EC2 必须根据用户的具体场景因地制宜，具体问题具体分析，是一件持续迭代优化的工作。总而言之，充分运用云的弹性和了解不同 EC2 机型的关键参数，是我们每一个 AWS 用户必须掌握的技巧。
关于 Greptime 的小知识：
Greptime 格睿科技于 2022 年创立，目前正在完善和打造时序数据库 GreptimeDB，格睿云 GreptimeCloud 和可观测工具 GreptimeAI 这三款产品。
GreptimeDB 是一款用 Rust 语言编写的时序数据库，具有分布式、开源、云原生和兼容性强等特点，帮助企业实时读写、处理和分析时序数据的同时降低长期存储成本；GreptimeCloud 可以为用户提供全托管的 DBaaS 服务，能够与可观测性、物联网等领域高度结合；GreptimeAI 为 LLM 量身打造，提供成本、性能和生成过程的全链路监控。
GreptimeCloud 和 GreptimeAI 已正式公测，欢迎关注公众号或官网了解最新动态！
官网：https://greptime.cn/
GitHub: https://github.com/GreptimeTeam/greptimedb
文档：https://docs.greptime.cn/
Twitter: https://twitter.com/Greptime
Slack: https://greptime.com/slack
LinkedIn: https://www.linkedin.com/company/greptime/
