aws 7宗罪

发表于 2024-07-31 分类于樱桃沟本文字数： 2.9k 阅读时长 ≈ 3 分钟

作为一个用了很多年的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

仅出口互联网网关
Global Accelerator 加速器
NAT 网关
Network Firewall 防火墙端点
网络负载均衡器
AWS PrivateLink（接口 VPC 终端节点）
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

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的云厂商公司，你也没地方说理去。