AWS：避免那些“神圣的法案”时刻的一些技巧

云非常棒：几乎100％的可用性，几乎零维护，按需付费，最重要的是，它具有无限的可扩展性。

但是最后两个很容易把你咬回去，把那令人敬畏的事情变成一场噩梦。

有时您会看到类似的故事：

一周之内，我们积累了接近1万美元的账单。

AWS技巧

在这里，我将介绍一些技巧，这些技巧是我们从构建世界上第一个无服务器IDE的不那么顺畅的旅程中学到的，可以帮助其他人避免一些“有趣的”陷阱。

小心该配置！

我们了解到的一件事是永远不要低估配置的功能。

如果您阅读以上链接的文章，您会注意到这是一个简单的错误配置：一个CloudTrail日志配置，该日志配置将日志写入已经监视的存储桶之一。

您当然可以举出创建“服务循环”产生计费黑洞的更详尽，更有创意的示例，但是这个想法很简单：AWS仅与配置它的人一样聪明。

AWS技巧

（嗯，在上述情况下，是我的一位同事配置了它，而我是验证它的人；因此，如果您愿意，可以在这里停下来；））

因此，当您要提交新的配置更新时，请尝试重新考虑后果。你不会后悔的。

是S3，不是您的阁楼。

AWS估计有7％的云计费费用浪费在“未使用”的存储上，这些空间被不实际使用的内容所占用：过时的捆绑包，临时上载，旧主机等。

生活在水桶里

但是，确实，清理事情说起来容易做起来难。遗忘一个废弃的文件比保持跟踪并在需要的时候删除它太容易了。

可能出于相同的原因，S3提供了生命周期配置 –基于时间的自动清除计划。您只需说“如果它早于7天，则删除它”，它将在7天后消失。

这是免除临时存储（构建工件，一次性共享等）检查的理想方法。

AWS技巧

当您想从存储桶中删除大量文件时，生命周期配置也可以派上用场。而不是删除单个文件（这本身会产生API费用–删除是免费的，列表不是！），您只需设置一个生命周期配置规则即可在1天之内使所有内容过期。坐下来放松一下，而S3为您服务！

{"Rules": [{"Status": "Enabled","Prefix": "","Expiration": {"Days": 1}}]
}

或者，您可以将不再需要但不是很容易放手的东西移入Glacier中，而只需花费很少的存储成本；例如，对于archived的子路径下的内容：

{"Rules": [{"Filter": {"Prefix": "archived"},"Status": "Enabled","Transitions": [{"Days": 1,"StorageClass": "GLACIER"}]}]
}

但是在您这样做之前...

哎呀，它是版本化的！

（受到真实事件的启发。）

我设置了一个生命周期配置，以删除大约3GB的存储桶访问日志（显然是数百万个文件），并认为一切都很好–直到一个月后，我得到了与上个月相同的S3账单：(

事实证明该存储桶已启用版本控制，因此删除并不会真正删除该对象。

因此，启用版本控制后，您需要明确告知S3生命周期逻辑以：

丢弃非当前（已删除）的对象版本，以及
过期的旧删除标记

为了完全摆脱“已删除”内容和相关的删除标记 。

“简单”的存储服务就这么多了；）

CloudWatch是您的朋友

每当您想找出存储桶占用的总大小时，只需遍历AWS/S3 CloudWatch Metrics名称空间即可。无法（惊讶，意外）从S3本地检查存储桶的大小。甚至S3仪表板也依赖CloudWatch，那为什么不呢？

快速查看所有内容？（在bash上使用aws-cli和bc ）

yesterday=$(date -d @$((($(date +%s)-86400))) +%F)
for bucket in `aws s3api list-buckets --query 'Buckets[*].Name' --output text`; dosize=$(aws cloudwatch get-metric-statistics --namespace AWS/S3 --start-time ${yesterday}T00:00:00 --end-time $(date +%F)T00:00:00 --period 86400 --metric-name BucketSizeBytes --dimensions Name=StorageType,Value=StandardStorage Name=BucketName,Value=$bucket --statistics Average --output text --query 'Datapoints[0].Average')if [ $size = "None" ]; then size=0; fiprintf "%8.3f  %s\n" $(echo $size/1048576 | bc -l) $bucket
done

EC2：扫垃圾，塞Kong

EC2使管理您的虚拟机变得轻而易举–计算，存储和网络。但是，它的简单性也意味着它可能会留下一些未被注意的垃圾和计费漏洞。

AWS技巧

选择您的实例类型

创建新实例时有太多设置。除非有特定的性能要求，否则选择具有弹性块存储（EBS）支持的存储和2-4 GB RAM的T2类实例类型就可以满足大多数需求。

尽管有免费使用层的资格， t2.micro如果您的服务器可以在某个时候接收计算或内存密集型负载，则t2.micro可以成为PITA；在这些情况下， t2.micro倾向于简单地冻结（可能与CPU信用用尽有关），造成的麻烦多于其价值。

清理AMI和快照

我们习惯于将EC2实例的定期快照作为备份。其中一些被制作成机器映像（AMI），以供其他AWS用户重用或共享。

我们很容易忘记其他快照。

尽管不会按快照的完整卷大小计费，但是随着时间的推移，快照会增加大量的垃圾。因此，定期访问并清理EC2快照选项卡很重要。

此外，创建新的AMI通常意味着较旧的AMI已过时；也可以从AMI选项卡中 “注销”它们。

但…

罪魁祸首是AMI还是快照？

实际费用在快照上 ，而不在AMI本身上。

而且它变得棘手，因为注销AMI不会自动删除相应的快照。

通常，您必须复制AMI ID，转到快照，在描述字段中查找ID，然后核对匹配的快照。或者，如果您很勇敢（又懒惰），则选择并删除所有快照； AWS将阻止您删除AMI正在使用的那些。

同样，对于实例和卷

EC2实例运行时对计算计费；但它的存储量始终是收费的-直到删除为止。

当您终止实例时，卷通常会变得无用。但是，如果您使用了音量附件设置，那么帐户中可能会遗留分离的音量。尽管未附加到实例，但它们仍占据空间；因此AWS会向他们收费。

再次，只需转到“ 卷”选项卡，选择“可用”状态的卷，然后单击“删除”以永久删除它们。

标记您的EC2内容：实例，卷，快照，AMI和其他内容

AWS技巧

制作快照时，很容易忘记实例中的状态。或正在运行/已停止的实例的目的，似乎没有人对此承担所有权或责任。

命名和标记可以帮助避免令人不快的意外（“为什么要删除上个月的产品快照？！”）；并且还可以帮助您快速决定要扔的东西（“我们已经有了11-05主快照，因此只需删除早于该快照的所有内容”）。

您停止使用，我们开始计费！

有时，AWS Lords以神秘的方式工作。

例如，只要将弹性IP地址（EIP）附加到正在运行的实例上，它们就是免费的。但是一旦实例停止，它们就会按小时开始收费；或者它们以某种方式进入“分离”状态（未附加到正在运行的实例）。

有关您将要注册的服务的一些先验知识可以防止这种方式带来令人讨厌的惊喜。快速定价页面查找或Google可能会破坏交易。

每次使用付费与按次分配付费

许多AWS服务都遵循上述一种或两种模式。前者是微不足道的（您只需支付您实际使用的时间/资源，而在其余时间中享受零账单）并且很难错过；但是后者可能有点晦涩，很容易被忽视。

考虑一下EC2：您主要为实例运行时付费，但您也为存储（卷，快照，AMI）和网络分配（如非活动的弹性IP）付费，即使实例已停止几个月也是如此。

还有更多示例，尤其是在无服务器域中（我们自己更熟悉）：

Kinesis 按碎片小时收费-即使您所有碎片都处于闲置状态
DynamoBB 以“容量单位”为单位收取存储和读取/写入费用-幸运的是，这里有一个免费的免费套餐！
RDS （非常类似于EC2）对实例运行时收费，无论是忙还是闲（ Aurora Serverless似乎都试图在某种程度上对此进行更改）
无论您是否使用， KMS都会 为每个客户管理密钥（CMK）收取固定费用

AWS技巧

同时，某些服务秘密地建立了自己的监视，备份和其他“实用程序”实体。这些（虽然可能！）意味着行善，但它们可能会秘密渗入您的账单：

DynamoDB设置CloudWatch警报；即使删除了相应的表（至少在通过CloudFormation进行管理时），这些表也仍然保留。
RDS在终止以及日常维护期间（尤其是通过“默认” CloudFormation配置进行部署时）会自动创建实例卷快照；这些快照可以轻松添加您的存储配额

这些是我们AWS账单中经常出现的罪魁祸首；当然有更好的例子，但是您明白了。

CloudWatch（再次）

许多服务已经（或可以配置为）将使用情况指标报告给CloudWatch。因此，通过掌握哪些度量标准映射到哪个计费组件的一些领域知识（例如，S3存储成本由AWS/S3命名空间的所有条目中BucketSizeBytes度量标准的总和表示），您可以围绕CloudWatch构建完整的计费和监控解决方案指标（或将作业委托给DataDog之类的第三方服务）。

AWS技巧