aws使用技巧

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

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

偶尔您会看到类似的故事：

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

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

小心该配置！

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

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

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

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

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

是S3，不是您的阁楼。

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

生活在水桶里

但是，确实，清理事情说起来容易做起来难。 忘记遗留的文件比保持跟踪并在时间到来时将其删除要容易得多。

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

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

当您想从存储桶中删除大量文件时，生命周期配置也可以派上用场。 而不是删除单个文件（这本身会产生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使管理虚拟机变得很简单-计算，存储和网络。 但是，它的简单性也意味着它会留下一些未被注意的垃圾和账单泄漏的痕迹。

选择您的实例类型

创建新实例时，设置过多。 除非有特定的性能要求，否则选择具有弹性块存储（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和其他内容

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

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

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

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

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

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

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

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

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

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

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

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

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

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

CloudWatch（再次）

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

CloudWatch本身基本上是免费的 ，并且其指标具有自动汇总机制，因此您不必担心会被陈旧的垃圾所淹没，也不必担心容量超支。

帐单API

尽管AWS确实有专用的Billing Dashboard ，但每天登录并检查它并不是您要添加到议程中的事情（至少对于像您和我这样的API / CLI人士而言）。

幸运的是，AWS提供了一个计费API ，通过该API ，您可以在任何首选时间段内大致了解当前的未结帐单-按服务或实际API操作进行细分。

值得一提的是，该API并非免费：每次调用都需要您支付0.01美元。 当然，这可以忽略不计-考虑到必须支付数十甚至在某些情况下甚至成百上千的风险，值得一个月$ 0.30的计费监视器来追踪任何异常，以免为时已晚。

值得深思：通过支持Google Cloud Functions提供的无头Chrome ，一个人可以设置无服务器工作流，该工作流登录到AWS仪表板并为您检查账单。 有一些可以在空闲时间尝试的东西（如果有些聪明的人还没有一起破解过的话）。

帐单提醒

奇怪的是（或可能不是；）AWS没有提供一种对账单设置硬性限制的方法。 尽管整个网络上都有大量用户请求和令人不安的事件报告。 相反，它们为各种计费“级别”提供警报 。 您可以通过电子邮件或SNS订阅诸如“按限额的x％计费”和“超出限额”之类的通知（方便通过Lambda进行自动化 ！）。

我的建议：这是每个AWS账户的必备条件 。 如果我们拥有一个，那么到目前为止，我们已经可以节省数千美元。

组织账户

如果您想将AWS访问权限委派给第三方（测试团队，基于合同的开发人员，演示用户等），则最好通过将您的根账户转换为启用了整合账单的AWS组织来创建子账户。 。

（虽然可以使用IAM用户执行几乎相同的操作 ，但它不会提供资源隔离；所有内容都将填充在同一帐户中，并且可能需要艰苦的IAM策略才能在用户之间隔离实体。）

我们的CEO和同事Asankha 对此进行了非常全面的撰写，因此，我将止步于此 。

监控。

无需强调这一点-我无休止的漫谈应该已经表达了它的重要性。

所以，祝你好运！

翻译自: https://www.javacodegeeks.com/2018/11/aws-tips-avoiding-holy-bill-moments.html

aws使用技巧