AWS 中国区(EC2/RDS/Elasticache) 计算器分享 https://cloud.engineerdraft.com/

[ivyliner]

引子

看到前后端同学关于 React/Vue 进行各种有意义的"探讨", 作为默默无闻的运维同学决定不再沉默, 结合自己工作的问题, 偷偷造了一个轮子: AWS 中国区(EC2/RDS/Elasticache) 计算器分享 https://cloud.engineerdraft.com/

背景

公司的业务运行在 AWS 中国区上, 由于我们是一家有技(暂)术(不)追(盈)求(利)的科技创新公司, 在日常运维中, 我们在如何替老板节省成本上进行各种折腾(北京 Region 迁移 宁夏 Region, 实例调整和匹配, 预留实例, Spot Instance)等, 在这过程中我们经常会遇到这样的问题

• 我如何快速知道一台 EC2 的配置和各种价格(OnDeman, Not Upfront, etc)差别 ? 从而选择价格最优的机型.
• 目前线上 CPU Bound 的业务跑在一台 8 GB 内存的机器(C5.xlarge), 我可以换成其他的什么机型? 从而合理优化使用机型.
• 在迁移北京 Region 到 宁夏 Region 中, 我想要知道 AWS 在不同 Region 的价格差别多少? 从而评估迁移 Region 的收益.
• 业务要上线一个新的服务, 个新服务每个月大概的 AWS 费用支出多少? 从而合理评估项目的成本.
• AWS 中国在追赶 Global 的道路上前进了一步, 支持了一个新的机型 :-), 和旧机型(配置, 价格, 性能)对比变化了什么? 从而科学评估是否迁移新机型.

发现目前市面上并没有特别趁手的工具, 比较接近的是云势数据计算器, 个人最开始也是用了一阵, 总体上还是不错的, 但是在一些场景下(比如: 我需要快速找到一个机型不支持 search, 不能快速对比北京和宁夏实例的价格差别等), 所以自己造了一个轮子, 分享给大家, 希望可以帮助同样在使用 AWS 中国的同学.

特殊说明

由于定位是效率工具, 只考虑了 PC 上展示.

[Had]

首先,感谢.
先点一个实例,然后切换他的任何一个参数,就不好用了...

先点了看了看,有以下反馈,如果冒犯还请海涵:)
1. 快速知道配置和价格这件事做的还成,但是 CPU 的型号主频没有,另外价格我们也可能要了解 Convertible 的,可转换在新旧实例类型交替时,可以保证资产;另外说实话啊,以 AWS 的分类,基本上不算太有角色重合的配置要你选择
2. c5.xlarge 换成什么其实也很好确定...
3. 价格差异,大概默认 2/3 就好了... 当然你用来评估的,更精确一点也挺好
4. 新服务支出多少,其实实例部分是一些,另外一部分在 EBS 在流量,EBS 选不好也挺贵的
5. 大的方向看,ARM 系,AMD 2 代和 d/n 系以外,其他没有太特别的不一样的(一些小型号另说),中国区从 19 年上了 nitro 后,走的还不错

[joesonw]

点进去公司看有点 TJ 的 apex 的感觉.

[Had]

另外想说,offer file 其实比较迷,有时候快有时候慢.
举个例子,offer file 并不会告诉你,在 PG 9.6.16, 10.11, 11.6, 12.2 及以上版本,在宁夏,是有 r5/m5/t3 的,你就没办法体现出来了,而且,这个还挺重要...

[Had]

@Had emm 顺着这个思路,Aurora PG 11.6 在北京区是有 r5 系列的...

[Had]

ElastiCache 不支持 Heavy Utilization Reserved,不过这个倒是也不太重要了

另外再说一个非常重要的一点,即 Instance size flexibility
对于 RDS 和 EC2 的 RI,这个非常非常重要,我觉得你应该基于 normalization factor 计算,你算出来最基本的即 1 个 normalization factor 后,再去以此构建计算器,感觉更普适一些 (当然我不会说即便是 AWS 也会出现同一个 family 的 RI,因为 size 不一样,导致 1 个 factor 价格不一样的问题:)

最后再补充以下,以上所有的工作都建立在 RI 体系,如果你去 Savings Plan,就是另外一个世界了:) (不排除中国区上线哦

[ivyliner]

@joesonw 恩, 是的. 我们公司还缺大量的 node 工程师, base 北京, 杭州 , 感兴趣的话, 可以考虑加入我们.

[ivyliner]

@Had CPU 型号和主频加上了 :-)