aws 7宗罪

作为一个用了很多年的aws的用户,对于aws的有些问题实在是受不了,不得不写出来。

ec2网络

这个是最严重的,ec2熟悉Linux服务器的肯定知道防火墙有个connection track的数,这个我们通过prometheus的node exporter里(node_nf_conntrack_entries)也能看到。

我们也可以通过设置sysctl来进行设置

1
2
sysctl -w net.netfilter.nf_conntrack_max=2097152
echo "net.netfilter.nf_conntrack_max = 2097152" >> /etc/sysctl.conf

这里我就直接设置了200万,这种情况下只要cpu,内存和网络端口没有问题,就能继续用。不过aws ec2可不行。

而aws的connection track是在ec2上层的,所以除非你把aws专用的ena模块打入到内核里,那你是看不到这个机器到底有connection track是可用的。
https://docs.amazonaws.cn/AWSEC2/latest/UserGuide/monitoring-network-performance-ena.html

而aws虽然说如果你安全组对某些端口开放了0.0.0.0/0或者::/0,就可以不跟踪了,可是在如下场景里也一样是会被track的。
https://docs.aws.amazon.com/zh_cn/AWSEC2/latest/UserGuide/security-group-connection-tracking.html

  1. 仅出口互联网网关
  2. Global Accelerator 加速器
  3. NAT 网关
  4. Network Firewall 防火墙端点
  5. 网络负载均衡器
  6. AWS PrivateLink(接口 VPC 终端节点)
  7. AWS Lambda(Hyperplane 弹性网络接口)
    所以其实是很难不被track的。

而更可气的是,2核的服务器track上限居然就10万,而azure这点就比较大方直接就50万。不过这是不是也是azure老被攻击的原因呢?

ec2磁盘

ebs磁盘性能太低了。
https://docs.aws.amazon.com/ec2/latest/instancetypes/co.html#co_storage-ebs
这里可以看到2核的服务器才25M吞吐,这还是block size是128K的情况下,要是4K的呢,4K乘以800 自己算算是多少。

这云盘性能太差也算了,这个本地nvme的盘也一样性能巨差无比。
https://aws.amazon.com/cn/blogs/china/new-the-next-generation-i3en-of-i-o-optimized-ec2-instances/
你说一块1.25TB的nvme跟我说吞吐就325M,也是128K的情况下。你说现在市面上还有低于2GB读写的nvme ssd吗?

所有这些都是为了让你买更高规格CPU的ec2.

redis重启

aws 的 elasticache(redis) 重启是会清空数据的。

关于这个问题问过aws,得到的回复是认为redis就是一个缓存,不应该存储任何持久化的数据。我个人认为这个纯粹是扯蛋了,就算重新加载一下一个小时之前的rdb又能怎么样呢?

不过你可以看到aws的redis规格都很大,它们只是怕加载rdb的时间太长,所以才一直不愿意改。

mysql磁盘

你又见识过谁家的mysql监控不给客户使用了多少磁盘空间的吗? aurora mysql就是一个这样的产品。

你要想知道磁盘空间多大,那就得用收的钱来反推了。


这个也找过aws support,最好是让在账单里执行sql

1
2
3
4
5
6
7
8
9
10
11
12
SELECT line_item_usage_start_date,
line_item_usage_end_date,
line_item_resource_id,
line_item_line_item_description,
line_item_usage_type,
sum(line_item_unblended_cost) AS Cost,
sum(line_item_usage_amount) AS Usage
FROM "您的报告名称"
WHERE line_item_resource_id like '%$instance name%'
AND line_item_line_item_type = 'Usage'
GROUP BY (1,2,3,4)
ORDER BY line_item_usage_start_date ASC

要这样我合并这么麻烦,直接在数据库执行sql也能查出来

1
SELECT table_schema "DATABASE NAME", sum(data_length + index_length)/1024/1024/1024"database_size_in_gb" FROM information_schema.TABLES GROUP BY table_schema;

mysql还有个问题,居然还有针对iops收费的。这个aws真是很有创意。所以你要用aws的aurora之前就得先看看自己的钱包够不够了。

还有这个东西说这个版本不支持就不支持了,想要支持,那就加倍付费。你说人这收费,要说多霸道就多霸道。
https://docs.aws.amazon.com/zh_cn/AmazonRDS/latest/UserGuide/extended-support.html

跨az价格

以前用云,没有听说过同一个region内不同az之间的流量是居然要收费的。这个oracle云也没这个费用啊。可人aws就是收了,而且进和出还都收了。一份流量多倍价格。

而且aws sa会推荐你使用优秀架构,所谓优秀架构很多时候就是需要跨az,因为主要是单一az的可用性不高的原因。

跨az延迟

你说跨az收费吧,那就质量好一点。可aws居然不保证跨az网络的延迟,你说延迟个几毫秒也就算了,居然还有延迟几十秒的,虽然是偶现,但是感觉还是很不爽,收费的还能这样。

你要说免费的也就算了,毕竟像阿里云这样的也有跨az突然中断的问题,但是他们不收费啊。

目标组健康检查150秒加入

aws的nlb的后端如果出了问题,那要再被加入到nlb后端就需要150秒,也就是至少需要2分半种。这种默认值简直让人有点无语啊。这些都是生产环境啊。

而作为它的竞争对手的, 无论我们看alb还是nlb, 这个时间也都是远远少于aws的。


后记,其实还有很多的地方aws是有问题的。当然别人是no1的云厂商公司,你也没地方说理去。