ECS/EKS 相对于直接 EC2 的成本节省

Question

我读过很多博客，其中谈到将微服务队列从直接的 EC2 虚拟机迁移到 ECS 或 EKS 上的容器可以节省 25-50% 的成本。虽然这很有吸引力，但考虑到使用带有AWS Pricing Calculator 的一些简单模型进行的成本估算，我正在摸不着头脑。我确信我在下面的估计中过度简化了这个问题，但价格差异的规模几乎是五倍（68 美元对 319 美元），这就引出了一个问题，成本节省在哪里？

例如，假设一个包含 8 个服务的小型集群在 [small t4g][2] 上运行良好：

| Instance   | EC2 Type  | vCPU | Mem (GB) | Storage (GB) | Monthly Cost |
| ---------- | --------- | ---- | -------- | ------------ | ------------:|
| Service 1  | t4g.small | 2    | 2        | 8            | USD 8.47     |
| Service 2  | t4g.small | 2    | 2        | 8            | USD 8.47     |
| Service 3  | t4g.small | 2    | 2        | 8            | USD 8.47     |
| Service 4  | t4g.small | 2    | 2        | 8            | USD 8.47     |
| Service 5  | t4g.small | 2    | 2        | 8            | USD 8.47     |
| Service 6  | t4g.small | 2    | 2        | 8            | USD 8.47     |
| Service 7  | t4g.small | 2    | 2        | 8            | USD 8.47     |
| Service 8  | t4g.small | 2    | 2        | 8            | USD 8.47     |
| **Totals** |           | 16   | 16       | 64           | USD 67.76    |

如果我要迁移到 ECS/EKS 并购买一些具有同等 vCPU 的更大 c5，我猜我需要完成同样的事情：

| Instance   | EC2 Type   | vCPU | Mem (GB) | Storage (GB) | Monthly Cost |
| ---------- | ---------- | ---- | -------- | ------------ | ------------:|
| Service 1  | c5.2xlarge | 8    | 16       | 32           | USD 159.42   |
| Service 2  |            |      |          |              |              |
| Service 3  |            |      |          |              |              |
| Service 4  |            |      |          |              |              |
| Service 5  | c5.2xlarge | 8    | 16       | 32           | USD 159.42   |
| Service 6  |            |      |          |              |              |
| Service 7  |            |      |          |              |              |
| Service 8  |            |      |          |              |              |
| **Totals** |            | 16   | [32][1]  | 64           | USD 318.84   |

正如我所提到的，我确信这是一个幼稚的比较，但我认为我最终会进入同一个球场，并且不会偏离 5 倍。我知道 ECS/EKS 将为我提供更好的资源利用率，但为了收支平衡，需要将效率提高 470%，这似乎不合理。

[1]：虽然 c5 的内存是两倍，但考虑到 mem:vCPU 的比例为 1:10，我认为这不会显着增加增量。

[2]：假设 1 年预留，EC2 实例节省计划，无预付费用

Answer 1

比较无效，因为它们是不同的产品，所以就像 Vikrant 所说的那样，它是将苹果与橙子进行比较。

t4g 是一个可突增的 CPU 实例

• 适合流量高峰的网站
• 用户数量相对较少（访问者数量激增）

在t4g出来之前，有t3a、t3、t2、t1……每一代都以更低的价格提供更好的性能。它也基于引力子处理器，而不是英特尔至强 C5 正在使用的处理器。此外，您还考虑了保留实例。

当 t4g 实例的 CPU 积分用完时...

T 实例非常实惠，因为一旦 CPU 积分用完，CPU 就会减速到爬行。 （例如在微型实例中为 10%）

C5 用于高且恒定的 CPU 负载

• 首先，价格与几个月前发布的新产品相比没有竞争力。
• 此外，它不提供可突增的 CPU 性能
• C5 提供高稳定的原始 CPU 功率
• 专注于 CPU 和相对较少的 RAM
• C5 提供更好的网络带宽

C5 适用于 CPU 负载持续较高的应用程序。 Web 服务器通常不对 CPU 的要求很高，并且当流量模式发生变化时工作负载会达到峰值。

除非对于响应时间要求非常快的网站，涉及 CPU 大量计算，T 系列实例更适合 Web 服务器。

当然，如果网站为多个时区的大量用户提供服务，那么工作量会更高且更稳定。在这种情况下，C5 可能是更好的选择。

如果需要，您可以一直以 100% 的速度运行 CPU，CPU 积分没有任何问题，它不会变慢。它提供了始终如一的高性能 CPU 性能。

将 C5 与 T4g 结合使用

高访问量 Web 服务器的策略设置是使用 C5 提供非常可靠的基准性能，并使用 T 实例处理繁忙时段的额外流量。例如，食品订购平台可以使用 C5 处理基线客户订单，并让 T 实例处理午餐和晚餐前后的高峰时段。

这样，当流量下降时，T 实例将慢慢获得 CPU 积分。此外，如果 CPU 用完，您也不必担心服务器会变得非常慢（10% 速度），因为即使所有 T 实例都在减速，您也有一个非常快的 C5 实例来备份它。