十項快速檢查，確保你的 AWS 支出處于控制之中
在本文中，我們將向你展示如何檢查十種最常用的 AWS 服務是否可以輕松降低成本。
圖片
你是否對 AWS 賬單感到驚訝？或者，也許你繼承了一個 AWS 帳戶，并被告知 –“它有很多不同的應用程序……沒有人真正知道誰負責什么，最好不要刪除任何內容。”或者你可能只是覺得你的 IT 支出已經很長時間沒有被檢查其合理性了。
嗯，今天是你的幸運日！你將了解如何減少 AWS 賬單。在本文中，我們將向你展示如何檢查十種最常用的 AWS 服務是否可以輕松降低成本。
谷歌的“最常用的AWS服務”的鏈接列出了以下前十名：
- S3
- EC2
- Lambda
- Glacier
- SNS
- CloudFront
- EBS
- Kinesis
- VPC
01.S3/Glacier
S3 是幾乎所有 AWS 賬戶中最常用的服務之一，因此有一些簡單的方法可以降低 S3 成本，這真是太好了。我建議的第一件事是將你無意選擇存儲類型的所有項目移至智能存儲類型。AWS 提供了幾種不同的方式來存儲對象，你存儲對象的方式會影響它們對你的收費方式。例如，AWS 允許你選擇一種存儲計劃，該計劃存儲你不經常查看的對象的成本較低，但每次查看時的成本會稍高一些。這稱為存檔訪問層。“智能”定價的巧妙之處在于，AWS 將使用其存儲指標讓你自動將未使用的項目移動到存檔訪問層。如果你想知道如何啟用此智能定價，
請訪問：
并啟用配置。
圖片
如果你有經常編輯的對象（你可以使用訪問日志來檢查它們的編輯頻率）并且這些對象啟用了版本控制，那么你可以禁用版本控制以節省資金。如果啟用版本控制，則每次修改或刪除對象時，AWS 都會進行備份，你需要付費。通過禁用版本控制，你將失去未來的備份以及為這些備份支付的費用。或者，如果你想在短時間內保留這些備份，但希望最大限度地降低成本，請考慮使用生命周期規則來使舊版本過期（有關如何執行此操作的更多詳細信息，請參閱下面）。請注意，你需要進入并清除已創建的舊備份。
如果你需要備份，請考慮定期備份（每周一次或每月一次）而不是版本控制。你可能以前聽過并且在上面聽過，但值得重復的另一個建議是使用生命周期規則來使舊對象過期。AWS 允許你設置要在 n 天后刪除的項目。
你可以通過在每個有意義的存儲桶上使用此功能來減少賬單。
有關啟用生命周期的具體說明簡短而有趣。
轉到：
https://s3.console.aws.amazon.com/s3/management/YOUR_BUCKET_NAME_HERE/lifecycle/create?reginotallow=YOUR_REGION_HERE 并填寫所需的規則。這是一個使舊對象過期并最終刪除它們的示例。
圖片
你可能還注意到上面的屏幕截圖包括“刪除過期的刪除標記或不完整的分段上傳”。將大型對象上傳到 S3 分段上傳時，如果失敗，就會一直等待，直到你進來清理它們，這樣可以節省大量費用！
02.EC2
EC2 計費可以說是最直接但也是最難省錢的服務。歸結為：(1) 不要過度配置，(2) 關閉不使用的內容，(3) 告訴 AWS 你計劃使用的量。
不過度配置聽起來很難。部分是這樣，但 AWS提供了方法來幫助我們。你可以轉到 Trusted Advisor，通過轉到 Trusted Advisor 成本優化控制臺并查看“低利用率 Amazon EC2 實例”部分，查看哪些 EC2 實例大小不合適。我建議你一次調整 1 個實例大小，并確認調整后沒發生任何問題。
也許你有一個開發帳戶（或一個 生產/開發/任何類型的帳戶）并且有 EC2 實例，并且它們在被使用中......但也許不是一直如此。在這種情況下，“關閉不使用的東西”會變得更加復雜，但并非無法撤消。在Trek10，我們讓客戶訪問我們自己的“EC2 Instance Napper”，它使用 AWS 標簽在EC2 實例不使用的時間段內關閉 EC2 實例，并在需要工作時自動重新打開這些 EC2 實例。對此還有許多其他解決方案，從編寫自己的腳本到使用 EC2 Instance Scheduler。（如果你不知道特定的 EC2 實例或一組 EC2 實例的用途，則可加分）這是一個很棒的工具，可以通過每天越來越長時間地關閉實例來開始“如果壞了就尖叫”的測試，直到他們永久關閉。
最后，你可能以前聽說過另一種方法—使用 RI 或Savings Plans。如果你告訴 AWS 你將在計算資源上花費多少，AWS 就會向你收取更少的費用。我知道我知道。你想說“但我不知道需要做什么，我無法承諾在 11 5 2 個月內擁有指定的計算能力”。我在這里告訴你……是的，你可以！只需承諾你能想象到的最小的Savings Plans即可。當你更加輕松地做出承諾時，你會感覺良好并開始朝著節省更多的方向前進。
03.Lambda
這一個并不像其他的那么容易。對于初學者來說，如果你使用 Lambda，與使用其他計算資源相比，你可能會節省很多。使用 Lambda 時省錢的最佳方法是找到最佳內存設置，或者我喜歡稱之為“收費點”。AWS 根據使用 Lambda 執行次數、每次執行花費的時間以及執行分配的內存的公式向你收取 Lambda 費用。你的調用次數可能是相對可預測的，但隨著你添加更多內存，該函數可能會運行得更快。這意味著通過調整內存分配設置，你可以優化成本。
為了找出“費用點”，我們需要使用標準有效負載測試一些不同的調用，同時調整每次調用的內存設置并記錄調用花費的時間。下面的示例采用一個基本的 Lambda 函數，該函數從 S3 中提取信息，并嘗試三種不同的內存設置：124MB、512MB 和 1024MB。要繼續操作，請選擇一些內存閾值并轉到 Lambda 控制臺。然后手動調用該函數并記下分配的時間（參見粉色方塊）和分配的內存（參見藍色方塊）。請注意，無論負載如何，我的 Lambda 都會執行相同的操作，請確保在測試時放入相似/相同的負載，如果負載不可知。
圖片
為了準確評估平均運行時間，我建議對每個內存設置多次執行此操作。我的示例僅執行 4 次調用，但我建議至少連續進行 20 次測試，并進行后 10 次調用（前 10 次調用有助于避免冷啟動)
圖片
一旦你準確獲得了每個關聯內存設置的平均持續時間，請前往 https://aws.amazon.com/lambda/pricing/并轉到 lambda 計算器。我使用 1,000,000 次調用的示例，并填寫每個平均持續時間以及分配的內存。
圖片
最終價格為：
128MB: 9.24 USD
512MB: 7.30 USD
1024MB: 10.95 USD
因此，在我們的示例中，“收費點”內存設置為 512MB。
閱讀上述成本細分步驟后，根據你的場景，你可能渴望一種更自動化的方法來確定最佳內存設置，該方法涉及更少的谷歌表格和更多代碼。那么，你是幸運的！查看 AWS Lambda Power Tuning，這是一個開源項目，可以讓你部署一系列函數并以代碼定義的方式測試內存設置。最后，如果我不提一下 AWS 自己解決這個問題的方案：AWS Compute Optimizer，那就太失職了。
04.SNS
SNS 是一項高度“管理”的托管服務。這意味著沒有太多手段可以用來減少賬單。確保你的 SNS 成本盡可能低的最快、最簡單的方法是確保你使用 us-east-1、us-west-2 或 us-east-, 2，因為這些區域的 SNS API 調用和傳輸方法的整體成本最低，盡管許多區域與某些 API 調用/傳輸方法相關。
05.CloudFront
很好用且很老的CloudFront。在它不便宜之前，它是非常便宜的。
首先，讓我們抓住這最簡單的勝利。CloudFront 基本上將你的內容存儲在全球各地，AWS 存儲內容的位置越多，向你收取的費用就越高。要減少 CloudFront 賬單，你可以通過轉到控制臺并單擊設置編輯來減少 AWS 存儲數據的位置數量，并更改價格等級（按照紅色圓圈操作）。
圖片
圖片
請注意，這意味著你向非美國/歐洲地區提供的內容將會變慢。如果這會給你的企業帶來問題，那么也許這不是一個需要降低的成本。
其次，如果你分發大量流量，你可以聯系 AWS，讓他們知道你愿意每月承諾 10+ TB 的數據并開始討價還價。我建議在提交 10+ TB 的 CloudFront 數據之前與 AWS 專業認證架構師進行討論，看看是否有更好的方法來分發必要的數據。
最后，雖然 AWS 在世界各地存儲你的內容，但它們會根據從 CloudFront 提取的數據量向你收費。通過告訴你的用戶將數據在瀏覽器中緩存更長時間，他們將減少返回 AWS 的頻率，從而減少下載的數據。請注意，這確實意味著從你那里接收內容的人可能無法獲得最新內容，因此，這是一個根據更新內容的頻率進行調整的解決方案。為了更好地了解如何編輯緩存配置，AWS 此處提供了一些有用的說明。
06.EBS
我最喜歡的兩種降低 EBS 成本的方法在聚會上大受歡迎。主要是因為它們既快速又簡單。第一個是使用 AWS 的 Trusted Advisor。他們有許多不同的成本優化檢查可供查看，但具體而言，請查看“未充分利用的 Amazon EBS 卷”。此部分向你展示了它認為可以縮小的所有 EBS 卷或未附加到實例的 EBS 卷（因此可能可以被清理，除非它們以備份等其他方式使用）。
你所需要做的就是單擊每個卷 ID 超鏈接，如果該卷未在使用，請將其刪除！如果正在使用，你應該考慮減小 EBS 卷大小（這有點棘手，但按照此處的說明操作應該沒問題）。
你可以執行的第二個檢查是檢查是否有任何類型為“IOPS”的 EBS 卷。要檢查這一點，請輸入以下 URL（請確保將該區域替換為你使用的活動區域）：
你將希望控制臺看起來像這樣：
圖片
但是，如果你確實看到卷類型為 io1 或 io2 的 EBS 卷，請轉到 CloudWatch 并查看 EBS 卷的使用情況是否與文檔中的通用或 IO 卷更加一致。如果 IO 卷的使用量未超過通用閾值，請考慮按照 AWS 文檔切換卷類型。
07.Kinesis
Kinesis 是一個很酷的東西。在不進行應用程序更改的情況下，沒有大量快速且簡單的更改可以減少你的賬單，因此我們將它們分為少量應用申請和大量應用申請。
少量應用申請：
首先，看看是否可以減少支持一個流的分片數量。單個 Kinesis 分片可支持高達 1MB/秒和 1000 條記錄/秒的輸入速度和 2MB/秒的輸出速度。要查看你的 Kinesis 流正在使用多少記錄，請轉到 CloudWatch 并查看以下三個指標（在流級別）：GetRecords.Bytes、IncomingRecords 和 IncomingBytes。接下來，你將需要查看的指標求和并注意間隔（因為上面的指標以秒為單位）。然后你將可以查看該流有多少個分片。
現在，請確保你的Kinesis流數據保留時間盡可能低。為此，請在 CLI 中使用以下命令：
aws kinesis list-streams --region <<region-here>>
Grab all stream names
aws kinesis describe-stream --stream-name <<stream-name-here>> --region <<region-here>> | grep "Retention"
if the retention period is 24 hours you are done, otherwise you can enter the command
aws kinesis increase-stream-retention-period --stream-name RawReports --retention-period-hours 24 to reduce retention
圖片
更多特定應用：
接下來的步驟可能比我們之前的步驟需要更多花哨的步驟，因為它們需要應用方面的知識。為了使這篇文章盡可能保持應用程序的通用性，我將在本節末尾給出高級解釋并鏈接到更具體的說明。當你的應用程序將記錄放入 Kinesis 時，AWS 將僅接受 25KB 塊的有效負載。如果你想提交 26KB，則需要 2 個 put 請求，或者如果你想提交 50KB 的數據，則還需要兩個 put 請求。現在，如果你的應用程序在發現有效負載時發送有效負載，你最終會發出帶有無用空間的 PUT 請求。例如，如果你的應用程序提交兩個不同的 PUT 請求，一個包含 14KB 的數據，另一個包含 2KB 的數據，則第一個請求有 11KB 的未使用空間，第二個請求有 23KB 的未使用空間。如果你修改應用程序以將 14KB 和 2KB 有效負載捆綁到一個 16KB 有效負載中，則只需為 1 個 PUT 請求付費，而不是 2 個。要真正深入了解數據聚合如何為你節省資金，請查看此內容(https://towardsdatascience.com/save-amazon-kinesis-stream-costs-using-records-aggregation-79c8fd9ea748)。
08.VPC
有很多方法可以減少應用程序之間的流量，從而降低與 VPC 相關的成本。如果你的 EC2 實例正在與同一區域中的 S3 或 DynamoDB 進行通信，那么你可能會看到 AWS 賬單的一部分用于 NAT 網關流量。AWS 認為應用程序通過 NAT 網關與 S3/DynamoDB 進行通信，將其視為 AWS“外部”將數據傳輸到 AWS 。AWS 要求你為從 AWS 外部發送到 AWS 的數據支付數據傳輸費用。AWS一方面收取費用，另一方面也為我們提供了稱為Gateway VPC Endpoints的服務。網關 VPC 終端節點可讓你在同一區域的 VPC → Dynamodb 或 VPC → S3 之間免費傳輸數據。設置網關 VPC 端點實際上非常簡單，但我不想重復造輪子，因此我將在此處鏈接 AWS 的說明(https://docs.aws.amazon.com/vpc/latest/privatelink/vpce-gateway.html )。
09.SQS
我知道你在想什么……也許我不知道。但是，如果你花時間嘗試減少 SQS 費用，那么你可能會想“請不要向我推銷昂貴且有些復雜的批處理代碼更新，該更新需要經過大量測試。”好消息是，本篇文章專注于簡單的勝利，所以我會給你一個關于批處理應用程序更新的長篇大論，然后以更輕松的方式接入（這仍然需要一些應用程序更改，對此我感到抱歉）。
SQS 消息最大可達 256KB，但如果消息超過 64KB，該消息將被分解為 64KB 請求塊并作為單獨的 SQS 消息發送（即發送單個 150KB 消息將被分解為 3 條消息并按 3 個請求計費，而不是一個請求） 。為了減少你的 SQS 賬單，你可以編寫一個特殊的批處理函數來聚合消息并將它們壓縮為 64 KB 的塊，如果這聽起來像你感興趣的內容，我建議你閱讀此博客(https://www.moengage.com/blog/reduce-sqs-cost/ )。
現在進行更簡單的更改。根據 SQS 的工作方式，如果你調用 ReceiveMessage API，無論你是否獲得任何信息，你都需要付費。沒錯，所有 API 調用都算作請求并計費，即使是空的調用也是如此。因此，如果你的應用程序設置為必須連接SQS 才能查看哪些消息可用，那么你可能會因大量返回為空的 AWS 調用而花費額外的錢。但是，AWS 為我們提供了解決方案……你可以告訴 AWS 在請求信息后等待 n 秒（其中 n 介于 \[1-20] 之間）以查看隊列中是否有消息。換句話說，你可以將 AWS 設置為如果隊列中沒有任何內容，則在返回信息之前等待最多 n 秒。假設你的應用程序可以等待，這是一個相當簡單的更改：
sqs = boto3.client('sqs')
# Create a SQS queue with long polling enabled
response = sqs.create_queue(
QueueName='EXPENSIVE_QUEUE_NAME',
)
sqs = boto3.client('sqs')
# Create a SQS queue with long polling enabled
response = sqs.create_queue(
QueueName='CHEAPER_QUEUE_NAME',
Attributes={'ReceiveMessageWaitTimeSeconds': '20'}
)更好的是，如果你的應用程序對信息的時間敏感性要求不高，那么可以考慮減少訪問SQS的次數（比如，僅在特定的時間間隔內排空隊列）。
10.CloudWatch Metrics
從技術角度來說，CloudWatch指標并不在top10節約成本的排行榜中，但我有一些快速提示可以讓你的賬單省下不少錢，而且我已經把S3和Glacier組合起來作弊了，所以我覺得我還是應該把它提一下。本技巧僅對使用采集 CloudWatch 指標的監控工具（例如 Datadog）的用戶有幫助（我們推薦使用 Datadog - 請在此處查看我們使用 Datadog 所做的所有很酷的事情）。從更高層面來看，這些類型的監控工具的作用是每 n 分鐘調用 AWS 并獲取包括 x、y、z 服務在內的指標列表。要減少賬單，你可以增加 n 以便減少返回 AWS 的頻率，這意味著更少的 API 調用，意味著更低的賬單。或者，你可以減少服務數量，更少的服務意味著更少的 API 調用，意味著更低的費用。
如果你想知道通過這種方法可以節省多少錢，首先進入Cost Explorer并查看是否存在大量的“GetMetricData”API操作費用，請單擊此處獲取預填充的 Cost Explorer 查詢。
圖片
在上圖中，該 AWS 賬戶僅在 CloudWatch get api 成本上就花費了近 1000 美元/月。
接下來，轉到你的監控工具（如果使用 Datadog，請專門前往此處：https://app.datadoghq.com/account/settings#integrations/amazon-web-services。你需要做的是刪除/取消選中你未主動監控的任何 AWS 服務（見下圖）或控制面板。減少 Datadog 在調用 AWS 時必須獲取指標的服務數量，從而減少 API 調用數量，從而減少你的費用。此外，你可以使用 Datadog 開具賬單，并詢問 Datadog 訪問你的 AWS 賬戶的頻率（它們有不同的設置，例如每 5 分鐘、每 10 分鐘等）。如果你愿意，你可以要求 Datadog 減少他們訪問你的 AWS 賬戶的頻率（但請記住，這意味著你賬戶中的數據更新頻率會降低）。
圖片
如有相關問題，請在文章后面給小編留言，小編安排作者第一時間和您聯系，為您答疑解惑。
原文地址：https://www.trek10.com/blog/ten-quick-checks-that-your-aws-spending-is-under-control
