AWS のコスト削減をマスターする: 請求額を跳ね上げる間違い

会員限定のお話

ヤン・カメラス

フォローする

ほぼ無限のリソースを提供する AWS の機能は優れており、クラウドネイティブアプリケーションを構築するときにリソースの制約を考慮する必要はありません。ただし、経済的要因もあり、無限の予算を持っている人はいません。最近、会社の一連のアカウントに対する AWS の請求額を 65% 削減しました。これは、年間約 60,000 ドルのコスト削減に相当します。 AWS はコストを管理するための多数のサービスをすでに提供しているため、コストを管理するために豪華なソフトウェアやツールは必要ありません。コスト要因は、ほとんどのアカウントや企業でほぼ常に同じです。

強く推奨されるアプローチは、AWS のコストを少なくとも四半期ベース、理想的には月ベースでレビューすることです。これには、請求書を確認するだけでなく、AWS Cost Explorer を使用してサービスを詳しく調べることも含まれます。 Cost Explorer は、コストの原因についての十分な洞察を提供しますが、コストを削減する方法についての解決策は提供しません。コスト要因の多くについては、多くの場合、CloudWatch を使用してサービスの使用状況を分析する必要があります。これらのコスト要因とそれに対抗する方法を見てみましょう。また、AWS の公式ドキュメントや推奨事項には記載されていない多くのコスト要因についても説明します。

多くのビジネスで私が遭遇した最も一般的なコスト要因は、オーバープロビジョニングです。当然のことながら、オーバープロビジョニングは AWS ソリューションアーキテクト認定資格にも記載されています。これは、アプリケーションに必要な容量をはるかに超えるメモリとコンピューティング容量を備えたリソースをプロビジョニングすることを指します。これらは、メモリが多すぎる EC2 インスタンス、または過剰なメモリまたは長い実行タイムアウトが割り当てられた Lambda 関数である可能性があります。

わずか 512 MB のメモリで Lambda 関数をプロビジョニングするのは愚かに聞こえるかもしれません。ただし、実行統計で Lambda 関数の使用量が 400 MB 未満であることが示された場合は、割り当てられたメモリを減らすことを検討する必要があります。多くの開発者にとって一般的なアプローチは、メモリが多すぎて実行タイムアウトが長すぎる状態で Lambda をデプロイすることです。ラムダが API ゲートウェイの背後にある場合は、とにかく最大実行が 30 秒に制限されます。 Lambda の計算能力または利用可能な vCPU は、割り当てられた…