天价账单,被aws薅羊毛了

kkzzq 2026-07-17 18:51 1

就做个新手任务,明明把数据库删掉了,提交工单了看后续

最新回复 (36)
  • lindar 07-17 18:51
    1

    WTF

  • Jiuqi 07-17 18:51
    2

    慈禧当年没还完的被判给你了?

  • Mosasaurus 07-17 18:51
    3

    不会给你取消的,会告你

  • 静静 07-17 18:52
    4

    🐂🍺

  • 美女约吗 07-17 18:52
    5

    图挂了

  • 4thebetter13 07-17 18:52
    6

    这咋办

  • jasperwill 07-17 18:52
    7

    我擦,做了啥这么高的账单

  • easton 07-17 18:53
    8

    出bug了吧

  • adou 07-17 18:53
    9

    这是干了啥。 ^-^

  • sivn 07-17 18:53
    10

    啥情况

  • ruxhao 07-17 18:53
    11

    只是废个号吧,总不能真告你 ^-^

  • zzznmzz 07-17 18:55
    12

    ^-^

  • helloword 07-17 18:55
    13

    这个图牛逼,4300个

  • jkjoy 07-17 18:56
    14

    你已经是我看到的第三个了

  • http401 07-17 18:56
    15

    ^-^ ^-^ ^-^

  • kkzzq 楼主 07-17 19:00
    16

    @jkjoy #14 出bug了把,我就算数据库开到死也不会这么多吧?

  • iseeyoudream 07-17 19:02
    17

    怎么今天AWS那么多天价账单

  • hjkl 07-17 19:03
    18

    四千万现在都排不上号了

  • Grok 07-17 19:04
    19

    出bug了可能,隔壁v2有个21亿的

  • fireflyskyshy 07-17 19:04
    20

    这得开多大的数据库啊 ^-^

  • mapleren 07-17 19:04
    21

    怎么那么多人发账单

  • aiocy 07-17 19:05
    22

    刚刚还有个1000亿的 ^-^ bug吧

  • almy 07-17 19:06
    23

    房子做噩梦了

  • pangzm 07-17 19:08
    24

    AI说的,不关我事:


    - 违背了 AWS 的默认服务配额(Service Quotas): AWS 对所有的账号(尤其是新手账号或普通账号)都设置了严格的硬性资源上限。默认情况下,单个账号在单个区域内能创建的 RDS(关系型数据库)实例数量是非常有限的(通常在 40 个左右)。截图显示这笔巨款主要来自“Relational Database Service”,但在默认配额下,系统根本不允许你创建足够多的数据库来产生这种级别的费用。

    - 金额在物理和数学上极度不合理: 图中显示“本月”花费高达 4,385万美元(US$43,859,970.20)。我们来算一笔账:即使开通 AWS 最顶配、最昂贵的企业级 RDS 实例(单台每月最高花费大约在数万美元级别),要在不到一个月的时间里烧掉 4,000 多万美金,需要同时运行一千多台最顶配的服务器。对于一个自称做“新手任务”的用户,且不说他是否有这个技术能力去编写并发脚本,AWS 官方也绝对不可能在没有企业级资质审核的情况下给他批复这么高的配额。

    **伪造成本极低: **这种截图不需要高超的 PS 技术。任何登录了 AWS 后台的用户,只需要按下键盘上的 F12 键打开浏览器的“开发者工具”,定位到金额对应的网页代码,几秒钟就能把账单金额从 $0.00 改成任何夸张的天文数字。


    总结:

    新手用云服务忘记关机器被“反撸”几百到几千美元确实是常有的事,但达到几千万美元这种国家级项目的预算规模,纯属网友修改网页数据在发帖整活。

  • schoskm 07-17 19:09
    25

    成百上千亿的有,你这算少的 ^-^

  • kkzzq 楼主 07-17 19:10
    26

    @pangzm #24 没整活,好多人这样。应该是出bug了

  • Bradlin 07-17 19:10
    27

    我的天,这什么操作

  • 鲁班 07-17 19:11
    28

    这账单真吓人 ^-^

  • 霏雪纪流年 07-17 19:12
    29

    这辈子出不了国了

  • hugsky 07-17 19:13
    30

    天文数字

  • DEBUGBin 07-17 19:15
    31

    账单好吓人

  • 橙子卡网 07-17 19:26
    32

    卧槽。 命都不值这么多

  • adou 07-17 19:28
    33

    刚才去搜了一下,官方好像在修了。

    地址是公告地址

  • CIYYYT 07-17 19:32
    34

    也是第一件见大户了 ^-^

  • 辟支独绝 07-17 19:33
    35

    原本我想说 准备卖房

    看来我还是缺乏点想象力

  • pangzm 07-17 20:50
    36

    @kkzzq #26 看到官方消息了,确实是真的。


    不准确的预估账单数据

    太平洋时间7月17日凌晨4:58, 我们正在努力解决影响计费和成本管理控制台中显示的预估成本和使用量数据的问题。我们正在积极并行实施多项缓解措施。第一项措施是将预估账单计算恢复到上次已知的有效计算方式。采用此方法后,客户将只能看到截至7月15日的成本和使用量数据,但虚高的成本数据将被移除。第二项措施是回滚最近对计费计算子系统的更改。显示的预估账单与实际使用量和费用不符。目前客户无需采取任何操作。问题缓解后,我们预计需要几个小时才能完全解决,因为我们需要重新计算预估账单数据。我们将在太平洋时间上午6:00之前或如有更多信息时提供最新进展。

    太平洋时间7月17日凌晨3:52, 我们正努力解决影响计费和成本管理控制台中显示的预估成本和使用量数据的问题。正如之前所述,我们已确定根本原因是预估计费计算子系统中的单位定价存在问题。为防止显示更多不准确的计费预估,我们已暂停预估计费计算。目前看到正常计费预估的客户将继续看到这些预估,而看到过高预估的客户在问题解决期间,预估金额不会进一步增加。显示的计费预估并不反映实际使用量和费用。我们正继续努力彻底解决此问题。问题解决后,我们预计需要数小时才能完全解决,因为我们需要重新计算预估计费数据。目前客户无需采取任何行动。我们将在太平洋时间上午5:00之前或如有更多信息时提供最新进展。

    太平洋时间7月17日凌晨3:03, 我们正努力解决影响计费和成本管理控制台中显示的预估成本和使用量数据的问题。我们已确定根本原因是预估计费计算子系统中的单位定价存在问题,目前正在进行修复。显示的预估计费金额与实际使用量和费用不符。目前客户无需采取任何行动。问题修复后,我们预计需要数小时才能完全解决,因为我们需要重新计算预估计费数据。我们将在太平洋时间凌晨4:00之前或如有更多信息时提供最新进展。

    太平洋时间7月17日凌晨2:07 自 太平洋时间7月16日晚上7:38起,我们在“计费和成本管理控制台”中开始显示错误的预估账单数据。我们的工程团队正在调查根本原因。我们将在太平洋时间凌晨3:00之前发布最新进展,如有更多信息,我们将提前发布。

    7 月 17 日凌晨 1:33(太平洋时间) 我们正在调查 Cost Explorer 显示不准确的预估账单数据的问题。

* 帖子来源NodeSeek
返回