【動画レポ】JAWSDAYS 2024 E-4 全方位でのAWSコスト管理：最適化、削減、そしてガバナンス〜AWS User Group Japan JAWS-UGチャンネルから

2024年6月28日 20:30

今回は2024年3月2日（土）に池袋サンシャインで開催されたJAWSDAYS 2024のセッション動画が公開されていたのでその中からピックアップしたいと思います。
今回はその中で最近話題のAWSコスト最適化についてのセッションを紹介します。

スピーカー紹介

松浦　翼さん
株式会社QUICK E-Solutions
クラウドプラットフォーム本部AWSプラットフォームグループ

AWSでのコスト管理の課題

コスト管理者・エンジニアからみて
・料金関連の参照権限が与えられていない
・共通リソースは部門合同なため放置されがち
・とりあえずRI/SP使っておけば・・・という安易さ

請求情報やAWS Cost Explorerが利用できない環境下でのReserved Instance（RI）/Saving Plans（SP）の購入の判定方法

⇒RI/SPを購入する必要があるが、請求関連情報の参照権限がない方向け

LambdaやAWS CLIを使用してCloudWatchのメトリクスから稼働状況を確認し判断基準とすることが可能

RI/SPおさらい

RI（Reserved Instance）が購入可能なAWSサービス
・EC2、RDS、ElasticCache、OpenSerch Service、Redshift

SP（Saving Plans）が適用可能なAWSサービス
・EC2、Fargate、Lambda、SageMaker

RI/SPの活用を検討するべきケース
・長期間稼働している
・長期間コミットメントが予測されるもの
〜請求情報が参照不可でもCloudWatchメトリクスから情報抽出して判断に活用

RI（Reserved Instance）の購入判断

EC2の例
Lambdaで各インスタンスの情報を取得/計算
　⇒インスタンスが起動している時間の割合を把握し判断の基準にする
・直近24時間のCPU利用率のメトリクスを１時間おきに取得
・CPU使用率が1％以上の時間帯の数を数え24時間で割る

⇒上記結果をAWS Priceing Calcuratorでシミュレーション
　稼働率を基にオンデマンドでの料金を確認しコスト削減度合いを確認可能

SP（Saving Plans）の購入判断

Faegateの例
Lambdaで各クラスター単位で予約されている情報を取得しSP購入を判断
・予約されているメモリ
・予約されているvCPU数
・SP購入においては稼働率が影響がないため１時間毎の使用率を確認

⇒抽出した結果から１日あたり無駄にならない容量分のSPを計算
・FargateのCompute Saving Planにて当該リージョンの料金を確認
・1時間単位のGP単位の料金×１時間あたりのvCPU単位の料金を計算
〜AWS Pricing Calcuratorで算出した通常料金と比較することで減価値算出

＜くわしくはこちらのブログで＞

共通リソースから考えるコスト管理

⇒AWS全体のコスト管理を行う方向け
共通リソース：NW系、セキュリティサービス、AWSサポート等

コスト配分タグでカバーできない範囲
・AWS共通リソース費用の按分
　DirectConnect、TransitGateway等
　セキュリティガバナンスに対する費用
　AWSサポート費用
・付与クレジットの適切な計算

⇒AWSの共通リソースとなり、明確なコスト配分が難しい部分

コスト管理の第一歩
　各部門のAWS利用者に応じて割合を算出し按分することが推奨

付与クレジットの適切な計算

AWSでクレジットが発生するケース
・PoC申請を行った時
・AWS側が起因の障害でSLAを下回った時
・クーポン配布時
・AWS Partner Network関連クレジット

クレジット適用時の優先順位
①クレジットを有するアカウント
②Organization内で支出が最も高いアカウント
③そのアカウント内で最も高い費用を持つサービス
④そのサービス内で最も高い費用を持つ在庫保有単位(SKU)

クレジットの考え方

・アカウント毎/システム毎の利用料に応じてクレジット分を按分して再計算
　共通リソースと同じ考え方
・クレジット減額分は代表部門（AWS基盤管理部門等）に割り当て、その他部門にはクレジット適用なしとして再計算

開発エンジニア目線で考えるコスト管理/削減

⇒AWSで設計/開発を行うエンジニアの方向け

コスト削減はRI/SPで満足しがち⇒それ以外の削減方法
・リージョン変更
・使用プロセッサの変更
・スポットインスタンスの活用
・ログ出力方式の検討

リージョン変更

・安易に「東京リージョン」としてしまいがち
・リージョンの変更によりコスト削減の余地があるかも
⇒検証環境など閉じた環境だと有効な可能性あり

使用プロセッサの変更

プロセッサ観点でのコスト削減
・ARMのコストパフォーマンスが高い
・Intel-AMD間の変更は比較的容易だがARMへの変更は考慮点が多い
・マネージドサービスはARMへのハードルが比較的低い

スポットインスタンスの活用

稼働に不安が残りがちですがうまくいくとコスト削減が期待
・いきなりダウンしても許容されるか

ログ出力方式の検討

どんなログでもCloudWatchLogs（意外に割高）に出力しがち
・監視を行いたいものだけ使用する

まとめ

・請求情報が見れなくてもCloudWatchメトリクスからRI/SPの購入検討は可能
・AWS共通リソースやクレジットもコスト管理
・RI/SPの使用以外でもコスト削減は可能

株式会社QUICK E-Solutionsでは以下のコスト削減ソリューションを提供

＜資料＞

ほかにもたくさんの動画があります

この記事が気に入ったらサポートをしてみませんか？