首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
ivyliner
V2EX  ›  DevOps

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

  •  
  •   ivyliner · 35 天前 · 763 次点击
    这是一个创建于 35 天前的主题,其中的信息可能已经有所发展或是发生改变。

    引子

    看到前后端同学关于 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 上展示.

    7 条回复    2020-06-06 12:10:15 +08:00
    Had
        1
    Had   35 天前
    首先,感谢.
    先点一个实例,然后切换他的任何一个参数,就不好用了...

    先点了看了看,有以下反馈,如果冒犯还请海涵:)
    1. 快速知道配置和价格这件事做的还成,但是 CPU 的型号主频没有,另外价格我们也可能要了解 Convertible 的,可转换在新旧实例类型交替时,可以保证资产;另外说实话啊,以 AWS 的分类,基本上不算太有角色重合的配置要你选择
    2. c5.xlarge 换成什么其实也很好确定...
    3. 价格差异,大概默认 2/3 就好了... 当然你用来评估的,更精确一点也挺好
    4. 新服务支出多少,其实实例部分是一些,另外一部分在 EBS 在流量,EBS 选不好也挺贵的
    5. 大的方向看,ARM 系,AMD 2 代和 d/n 系以外,其他没有太特别的不一样的(一些小型号另说),中国区从 19 年上了 nitro 后,走的还不错
    joesonw
        2
    joesonw   35 天前
    点进去公司看有点 TJ 的 apex 的感觉.
    Had
        3
    Had   35 天前
    另外想说,offer file 其实比较迷,有时候快有时候慢.
    举个例子,offer file 并不会告诉你,在 PG 9.6.16, 10.11, 11.6, 12.2 及以上版本,在宁夏,是有 r5/m5/t3 的,你就没办法体现出来了,而且,这个还挺重要...
    Had
        4
    Had   35 天前
    @Had emm 顺着这个思路,Aurora PG 11.6 在北京区是有 r5 系列的...
    Had
        5
    Had   35 天前
    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
        6
    ivyliner   35 天前
    @joesonw 恩, 是的. 我们公司还缺大量的 node 工程师, base 北京, 杭州 , 感兴趣的话, 可以考虑加入我们.
    ivyliner
        7
    ivyliner   35 天前
    @Had CPU 型号和主频加上了 :-)
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2637 人在线   最高记录 5168   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 05:10 · PVG 13:10 · LAX 22:10 · JFK 01:10
    ♥ Do have faith in what you're doing.