云非常棒：幾乎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：避免那些“神圣的法案”时刻的一些技巧的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。