aws使用技巧

云非常棒：幾乎100％的可用性，接近零的維護(hù)，按需付費(fèi)，最重要的是，它具有無限的可擴(kuò)展性。

但是最后兩個(gè)很容易把你咬回去，把那令人敬畏的事情變成一場噩夢。

偶爾您會(huì)看到類似的故事：

一周之內(nèi)，我們積累了接近1萬美元的賬單。

在這里，我將介紹一些技巧，這些技巧是我們從構(gòu)建世界上第一個(gè)無服務(wù)器IDE的不那么順暢的旅程中學(xué)到的，可以幫助其他人避免一些“有趣的”陷阱。

小心該配置！

我們了解到的一件事是永遠(yuǎn)不要低估配置的功能。

如果您閱讀以上鏈接的文章，您會(huì)發(fā)現(xiàn)這是一個(gè)簡單的錯(cuò)誤配置：一個(gè)CloudTrail日志記錄配置 ，該日志配置將日志寫入已經(jīng)監(jiān)視的存儲(chǔ)桶之一。

您當(dāng)然可以舉出創(chuàng)建“服務(wù)循環(huán)”而產(chǎn)生計(jì)費(fèi)黑洞的更詳盡，更有創(chuàng)意的示例，但是這個(gè)想法很簡單：AWS僅與配置它的人一樣聰明。

（嗯，在上述情況下，它是我的一位同事配置的，而我是對其進(jìn)行驗(yàn)證的；因此，如果您愿意，可以在這里停下來；））

因此，當(dāng)您要提交新的配置更新時(shí)，請嘗試重新考慮后果。 你不會(huì)后悔的。

是S3，不是您的閣樓。

AWS估計(jì)有7％的云計(jì)費(fèi)費(fèi)用浪費(fèi)在“未使用”的存儲(chǔ)上，這些空間被不實(shí)際使用的內(nèi)容所占用：過時(shí)的捆綁包，臨時(shí)上載，舊主機(jī)等。

生活在水桶里

但是，確實(shí)，清理事情說起來容易做起來難。 忘記遺留的文件比保持跟蹤并在時(shí)間到來時(shí)將其刪除要容易得多。

可能出于相同的原因，S3提供了生命周期配置 –基于時(shí)間的自動(dòng)清除計(jì)劃。 您只需說“如果它早于7天，則刪除它”，它將在7天后消失。

這是自動(dòng)檢查臨時(shí)存儲(chǔ)（構(gòu)建工件，一次性共享等）的理想方法。

當(dāng)您想從存儲(chǔ)桶中刪除大量文件時(shí)，生命周期配置也可以派上用場。 而不是刪除單個(gè)文件（這本身會(huì)產(chǎn)生API費(fèi)用–刪除是免費(fèi)的，列表不是！ ），您只需設(shè)置一個(gè)生命周期配置規(guī)則即可在1天之內(nèi)使所有內(nèi)容過期。 坐下來放松一下，而S3為您服務(wù)！

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

或者，您可以將不再需要但不是很容易放手的東西移入Glacier中，而只需花費(fèi)很少的存儲(chǔ)成本 ； 例如，對于archived的子路徑下的內(nèi)容：

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

但是在您這樣做之前...

哎呀，它是版本化的！

（受到真實(shí)事件的啟發(fā)。）

我設(shè)置了一個(gè)生命周期配置，以刪除大約3GB的存儲(chǔ)桶訪問日志（顯然是數(shù)百萬個(gè)文件），并認(rèn)為一切都很好–直到一個(gè)月后，我得到了與上個(gè)月相同的S3賬單：(

事實(shí)證明該存儲(chǔ)桶已啟用版本控制，因此刪除并不會(huì)真正刪除該對象 。

因此，啟用版本控制后，您需要明確告知S3生命周期邏輯以：

• 丟棄非當(dāng)前（已刪除）的對象版本 ，以及
• 過期的舊刪除標(biāo)記

為了完全擺脫“已刪除”內(nèi)容和相關(guān)的刪除標(biāo)記 。

“簡單”的存儲(chǔ)服務(wù)就這么多了；）

CloudWatch是您的朋友

每當(dāng)您想找出存儲(chǔ)桶占用的總大小時(shí) ，只需遍歷AWS/S3 CloudWatch Metrics名稱空間即可 。 無法（驚訝，意外）從S3本地檢查存儲(chǔ)桶的大小； 甚至S3儀表板也依賴CloudWatch，那為什么不呢？

快速查看所有內(nèi)容？ （在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使管理虛擬機(jī)變得很簡單-計(jì)算，存儲(chǔ)和網(wǎng)絡(luò)。 但是，它的簡單性也意味著它會(huì)留下一些未被注意的垃圾和賬單泄漏的痕跡。

選擇您的實(shí)例類型

創(chuàng)建新實(shí)例時(shí)，設(shè)置過多。 除非有特定的性能要求，否則選擇具有彈性塊存儲(chǔ)（EBS）支持的存儲(chǔ)和2-4 GB RAM的T2類實(shí)例類型就可以滿足大多數(shù)需求。

盡管有免費(fèi)使用層的資格， t2.micro如果您的服務(wù)器在某個(gè)時(shí)候可以接收計(jì)算或內(nèi)存密集型負(fù)載，則t2.micro可以成為PITA。 在這種情況下， t2.micro傾向于簡單地凍結(jié)（可能與CPU信用用盡有關(guān) ），造成的麻煩多于其價(jià)值。

清理AMI和快照

我們習(xí)慣于將EC2實(shí)例的定期快照作為備份。 其中一些被制作成機(jī)器映像（AMI） ， 以供其他AWS用戶重用或共享 。

我們很容易忘記其他快照。

盡管不會(huì)按快照的完整卷大小計(jì)費(fèi) ，但隨著時(shí)間的推移，快照會(huì)增加大量的垃圾。 因此，定期訪問并清理EC2快照選項(xiàng)卡很重要。

而且，創(chuàng)建新的AMI通常意味著較舊的AMI已過時(shí)。 也可以從AMI選項(xiàng)卡中 “注銷”它們。

但…

誰是罪魁禍?zhǔn)专C AMI或快照？

實(shí)際費(fèi)用在快照上 ，而不在AMI本身上。

而且它變得棘手，因?yàn)樽NAMI不會(huì)自動(dòng)刪除相應(yīng)的快照 。

通常，您必須復(fù)制AMI ID，轉(zhuǎn)到快照，在描述字段中查找ID，然后核對匹配的快照。 或者，如果您很勇敢（又懶惰），則選擇并刪除所有快照； AWS將阻止您刪除AMI正在使用的那些。

同樣，對于實(shí)例和卷

EC2實(shí)例運(yùn)行時(shí)對計(jì)算進(jìn)行計(jì)費(fèi)； 但是它的存儲(chǔ)量始終是收費(fèi)的-直到刪除為止。

當(dāng)您終止實(shí)例時(shí)，卷通常會(huì)變得無用。 但是，如果您使用了卷附件設(shè)置，那么帳戶中有可能遺留了分離的卷。 盡管沒有附加到實(shí)例，但是它們?nèi)匀徽紦?jù)空間。 因此AWS會(huì)向他們收費(fèi)。

再次，只需轉(zhuǎn)到“ 卷”選項(xiàng)卡 ，選擇“可用”狀態(tài)的卷，然后單擊“刪除”永久刪除它們。

標(biāo)記您的EC2內(nèi)容：實(shí)例，卷，快照，AMI和其他內(nèi)容

制作快照時(shí)，很容易忘記實(shí)例中的狀態(tài)。 或正在運(yùn)行/已停止的實(shí)例的目的，似乎沒有人對此承擔(dān)所有權(quán)或責(zé)任。

命名和標(biāo)記可以幫助避免令人不快的意外（“為什么要?jiǎng)h除上個(gè)月的產(chǎn)品快照？！”）； 并且還可以幫助您快速?zèng)Q定要扔的東西（“我們已經(jīng)有了11-05主快照，因此只需刪除早于此的所有內(nèi)容”）。

您停止使用，我們開始計(jì)費(fèi)！

有時(shí)，AWS Lords以神秘的方式工作。

例如，只要將彈性IP地址（EIP）附加到正在運(yùn)行的實(shí)例上，它們就是免費(fèi)的。 但是一旦實(shí)例停止，它們就會(huì)按小時(shí)開始收費(fèi)； 或者它們以某種方式進(jìn)入“分離”狀態(tài)（未附加到正在運(yùn)行的實(shí)例）。

有關(guān)您將要注冊的服務(wù)的一些先驗(yàn)知識(shí)可以防止這種方式帶來的令人討厭的驚喜。 快速定價(jià)頁面查找或Google可能會(huì)破壞交易。

每次使用付費(fèi)與按次分配付費(fèi)

許多AWS服務(wù)都遵循上述一種或兩種模式。 前者是微不足道的（您只需支付實(shí)際使用的時(shí)間/資源，并在其余時(shí)間中享受零賬單），就很難錯(cuò)過； 但是后者可能有點(diǎn)晦澀，很容易被忽視。

考慮一下EC2：您主要為實(shí)例運(yùn)行時(shí)付費(fèi)，但您也為存儲(chǔ)（卷，快照，AMI）和網(wǎng)絡(luò)分配（如非活動(dòng)的彈性IP）付費(fèi)，即使實(shí)例已停止幾個(gè)月也是如此。

還有更多示例，尤其是在無服務(wù)器域中 （我們自己更熟悉）：

• Kinesis 按碎片小時(shí)收費(fèi)-即使您所有碎片都處于空閑狀態(tài)
• DynamoBB 以“容量單位”為單位收取存儲(chǔ)和讀取/寫入費(fèi)用-幸運(yùn)的是，這里有一個(gè)免費(fèi)的免費(fèi)套餐！
• RDS （非常類似于EC2）對實(shí)例運(yùn)行時(shí)（無論是忙還是閑）收費(fèi)（ Aurora Serverless似乎正在嘗試對此進(jìn)行一定程度的更改）
• 無論您是否使用， KMS都會(huì) 為每個(gè)客戶管理密鑰（CMK）收取固定費(fèi)用

同時(shí)，某些服務(wù)秘密地建立了自己的監(jiān)視，備份和其他“實(shí)用程序”實(shí)體。 這些（雖然可能！）意味著行善，但它們可以秘密地滲入您的賬單：

• DynamoDB設(shè)置CloudWatch警報(bào) ； 即使刪除了相應(yīng)的表（至少在通過CloudFormation進(jìn)行管理時(shí)），這些表也仍然保留。
• RDS在終止以及日常維護(hù)期間（尤其是通過“默認(rèn)” CloudFormation配置進(jìn)行部署時(shí)）會(huì)自動(dòng)創(chuàng)建實(shí)例卷快照 ；這些快照可以輕松添加您的存儲(chǔ)配額

這些是我們AWS賬單中經(jīng)常出現(xiàn)的罪魁禍?zhǔn)?#xff1b; 當(dāng)然有更好的例子，但是您明白了。

CloudWatch（再次）

許多服務(wù)已經(jīng)（或可以配置為）將使用情況指標(biāo)報(bào)告給CloudWatch。 因此，通過掌握哪些度量標(biāo)準(zhǔn)映射到哪個(gè)計(jì)費(fèi)組件的一些領(lǐng)域知識(shí)（例如，S3存儲(chǔ)成本由AWS/S3名稱空間的所有條目中BucketSizeBytes度量標(biāo)準(zhǔn)的總和表示），您可以圍繞CloudWatch構(gòu)建完整的計(jì)費(fèi)和監(jiān)控解決方案指標(biāo) （或?qū)⒆鳂I(yè)委派給DataDog之類的第三方服務(wù)）。

CloudWatch本身基本上是免費(fèi)的 ，并且其指標(biāo)具有自動(dòng)匯總機(jī)制，因此您不必?fù)?dān)心會(huì)被陳舊的垃圾所淹沒，也不必?fù)?dān)心容量超支。

帳單API

盡管AWS確實(shí)有專用的Billing Dashboard ，但每天登錄并檢查它并不是您要添加到議程中的事情（至少對于像您和我這樣的API / CLI人士而言）。

幸運(yùn)的是，AWS提供了一個(gè)計(jì)費(fèi)API ，通過該API ，您可以在任何首選時(shí)間段內(nèi)大致了解當(dāng)前的未結(jié)帳單-按服務(wù)或?qū)嶋HAPI操作進(jìn)行細(xì)分。

值得一提的是，該API并非免費(fèi)：每次調(diào)用都需要您支付0.01美元。 當(dāng)然，這可以忽略不計(jì)-考慮到必須支付數(shù)十甚至在某些情況下甚至成百上千的風(fēng)險(xiǎn)，值得一個(gè)月$ 0.30的計(jì)費(fèi)監(jiān)視器來追蹤任何異常，以免為時(shí)已晚。

值得深思：通過支持Google Cloud Functions提供的無頭Chrome ，一個(gè)人可以設(shè)置無服務(wù)器工作流，該工作流登錄到AWS儀表板并為您檢查賬單。 有一些可以在空閑時(shí)間嘗試的東西（如果有些聰明的人還沒有一起破解過的話）。

帳單提醒

奇怪的是（或可能不是；）AWS沒有提供一種對賬單設(shè)置硬性限制的方法。 盡管整個(gè)網(wǎng)絡(luò)上都有大量用戶請求和令人不安的事件報(bào)告。 相反，它們?yōu)楦鞣N計(jì)費(fèi)“級(jí)別”提供警報(bào) 。 您可以通過電子郵件或SNS訂閱諸如“按限額的x％計(jì)費(fèi)”和“超出限額”之類的通知（方便通過Lambda進(jìn)行自動(dòng)化 ！）。

我的建議：這是每個(gè)AWS賬戶的必備條件 。 如果我們擁有一個(gè)，那么到目前為止，我們已經(jīng)可以節(jié)省數(shù)千美元。

組織賬戶

如果您想將AWS訪問權(quán)限委派給第三方（測試團(tuán)隊(duì)，基于合同的開發(fā)人員，演示用戶等），則最好通過將您的根賬戶轉(zhuǎn)換為啟用了整合賬單的AWS組織來創(chuàng)建子賬戶。 。

（雖然可以使用IAM用戶執(zhí)行幾乎相同的操作 ，但它不會(huì)提供資源隔離；所有內(nèi)容都將填充在同一帳戶中，并且可能需要艱苦的IAM策略才能在用戶之間隔離實(shí)體。）

我們的CEO和同事Asankha 對此進(jìn)行了非常全面的撰寫，因此，我將止步于此 。

監(jiān)控。

無需強(qiáng)調(diào)這一點(diǎn)-我無休止的漫談應(yīng)該已經(jīng)表達(dá)了它的重要性。

所以，祝你好運(yùn)！

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

aws使用技巧

總結(jié)

以上是生活随笔為你收集整理的aws使用技巧_AWS：避免那些“神圣的法案”时刻的一些技巧的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。