jsp网站建设技术案例,怎么自己制作小程序商城,南通企业网页制作,wordpress 行高云非常棒#xff1a;几乎100#xff05;的可用性#xff0c;几乎零维护#xff0c;按需付费#xff0c;最重要的是#xff0c;它具有无限的可扩展性。 但是最后两个很容易把你咬回去#xff0c;把那令人敬畏的事情变成一场噩梦。 有时您会看到类似的故事#xff1a; … 云非常棒几乎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 NameStorageType,ValueStandardStorage NameBucketName,Value$bucket --statistics Average --output text --query Datapoints[0].Average)if [ $size None ]; then size0; fiprintf %8.3f %s\n $(echo $size/1048576 | bc -l) $bucket
doneEC2扫垃圾塞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
