円安時代に再考するAWSコスト節約術（コンピュートリソース編：「EC2」「ECS」「Lambda」）：AWSチートシート

AWS活用における便利な小技を簡潔に紹介する連載「AWSチートシート」。今回はコンピュート系のサービスに焦点を当てて、コストを最適化するポイントを紹介します。

[沼崎伸洋，株式会社システムシェアード]

　皆さんご存じの通り、約30年ぶりの水準で円安ドル高となっています。「Amazon Web Services」（AWS）の料金計算はドルベースなので、この影響は避けられません。利用の規模は変わっていないとしてもこれまでコストをうまく最適化できていない場合、不必要なコストがこれまで以上に増大してしまう状態となっています。

　AWS活用における便利な小技を簡潔に紹介する連載「AWSチートシート」。今回は、コンピュート系のサービス「Amazon Elastic Compute Cloud」（EC2）、「Amazon Elastic Container Service」（ECS）、「AWS Lambda」に焦点を当てて、コストを最適化するポイントを4つ紹介します。

※各サービスの最新の利用料金に関しては公式の情報をご参照ください

• EC2利用料金
• ECS利用料金
• Lambda利用料金

ポイント1：日本以外のリージョンが利用できるかどうかを検討する

　ほぼ全てのAWSサービスはリージョンごとにリソースの時間、実行回数当たりの単価が設定されており、全リージョン一律の価格ではありません。下図は、EC2で同一条件の1台のインスタンスをさまざまなリージョンで見積もって比較した画像です。

　ここから理解できると思いますが、東京リージョンなどのアジアパシフィックリージョンは、北米リージョンと比較すると割高になります。

　今回比較したのはEC2ですが、この傾向はAWS全サービスでも同様です。

　もちろん、日本国内から利用されることが想定されるサービスでは国外のリージョンを利用することはレイテンシなどの観点から難しいかもしれませんが、技術検証、国外でも問題ない開発環境として利用する上では、北米リージョンなどの日本以外のリージョンを検討してみてはいかがでしょうか。

ポイント1まとめ

• 東京リージョンは比較的割高な料金設定
• 法的規制、社内ルールなどによって禁止されていない場合、開発、技術検証に利用する際、北米リージョンなどを検討してみる（場合によっては本番でもできないかどうかを検討する）

ポイント2：必要以上のキャパシティーを確保していないかどうか再検討する

　AWSでは、従来のオンプレミスで構築していたシステムと異なり、需要に応じて迅速にキャパシティーを追加、削減できます。AWSなどのパブリッククラウドでは基本的な概念ですが、いま一度下記ポイントが徹底されているかどうか再確認しましょう。

• システムに最適なマシンスペック、設定値を選定しているかどうか
• システムの利用率に応じて適切にスケールイン／スケールアウトしているかどうか

　「Amazon CloudWatch」のメトリクスで各リソースの利用率指標を確認し、設定値などに余裕を持たせ過ぎているようなら、低廉なスペックの需要が増大した際は、スケールアウト／スケールインなどで対処できるかどうか検討しましよう。

　EC2ならCPU、メモリ、ネットワーク帯域の利用率などを参考に、最適なインスタンスタイプを選定します。ECSも同様に、タスクのCPU、メモリの利用率を確認し、スケールアウト／スケールインを最適化します。Lambdaの場合は、実行時のログなどに利用メモリや実行時間が出力されるので、そちらを参考に、メモリの利用効率が高くなり、かつ実行時間も短い設定に変更して最適化するなどの対処が考えられるでしょう。

　以前、どこかの時点で検討したことがあったとしても、時間がたっているなら再度の見直しをお勧めします。

ポイント2まとめ

• 見込みなどで必要以上のキャパシティーを定常的に確保していないかどうか確認する
• 必要以上のキャパシティーを確保している場合は、リソースサイズを最適化し、スケールイン／スケールアウトも適切に設定する

ポイント3：さまざまな購入オプションからマッチするものを検討する。

　EC2、ECS、Lambdaについてはオンデマンド以外でさまざまな購入オプションが用意されています。自分たちの利用しているリソースに合った購入オプションを選択することで、大幅にコストを下げられる可能性があります。

• 定常的に確保しなくてもいいリソースについては、EC2やECSで「スポットインスタンス」「FargateSpot」を活用できるかどうか
• 長期で最低限確保しなくてはいけないリソースは「リザーブドインスタンス」（以降、RI）、「Savings Plans」（以降、SP）などの購入オプションを検討できるかどうか

　EC2、ECSではオンデマンド以外で、「スポットインスタンス」（「ECS Fargate」は「FargateSpot」）という、AWSでの余剰リソース枠がある場合にそれをオンデマンドと比較して割安で利用できる形態があります。RI購入オプションは長期（1年、3年のどちらかの期間）にリソース利用を予約して先払いなどを行い、割り引かれた価格で利用できます。SPは長期（1年、3年のどちらかの期間）に時間当たりの支払額（毎時ドル）を確約して通常の利用時より割り引いた価格で利用する形態となります。

　RIとSPの違いや注意点については、下記記事が図表を交えて分かりやすくまとめられています。

• EC2 でリザーブドインスタンス（RI）と Savings Plans （SP）のどちらを選ぶべきか？基準とするための最強の比較表を作ってみた | DevelopersIO

　RIではEC2のみが対象ですが、SPの「Compute Savings Plans」なら、ECS FargateとLambdaも割引の恩恵が受けられます。

　なお長期で先払いを選択した場合は現在のレートで請求されるので、今後もし円高基調に転じた場合、結果として高値づかみとなってしまう可能性があるのでご注意ください。

　スポットインスタンスについては、AWSで余剰リソースがない上に中断されてもリトライできる場合、中断シグナルを受け取ったときの処理をプログラムでハンドリングしていて適切に終了できるといったときに利用するといいでしょう。また検証などの場合は、停止／再開可能なスポットインスタンスを利用してもいいでしょう。

ポイント3まとめ

• オンデマンドだけでなくスポットインスタンスやRI、SPの購入オプションの中から最適なものを検討、選択する
• スポットインスタンスを利用する場合、中断が起きた場合を考慮してプログラムでハンドリングなどの対処をあらかじめ組み込んでおく

ポイント4：利用しているインスタンスタイプ、CPUアーキテクチャを見直す

　EC2では定期的に新世代のインスタンスタイプが公開されます。基本的に新世代のインスタンスタイプは同タイプの旧世代より価格が安く、性能の向上が見込めるといったメリットが多くなっています。

　下図は「t3.micro」とその新世代に当たるArmベースの「AWS Graviton2」プロセッサが利用されたインスタンスですが、1台当たり2ドル程度の差が出ています。

　CPUのアーキテクチャを見直すに当たっては、AWSにおいてEC2、ECS、Lambdaでx86（Intel）ではなくArmをCPUアーキテクチャとして利用するように設定するとx86を選択した場合より割安になり、処理効率も高くなる傾向があります。

　下図はEC2、ECS、LambdaでCPUアーキテクチャ以外を同条件にした場合の見積もりです。それぞれのサービスでArmを利用することで安くなっていることが分かると思います。

　なお、既存のシステムをArmプロセッサ上で動かす場合は、移行しても動作に影響がないかどうかなどは注意して確認する必要があります。

ポイント4まとめ

• インスタンスタイプなどを見直していない場合、同インスタンスファミリーの新しいものを利用する
• 新規作成でArmでも問題がない場合、まずArmが利用できるかどうかを検討する
• x86からArmに移行する場合、動作に影響がないかどうかを確認して移行をする

まとめ

　円安時代に再考するAWSコスト最適化（コンピュートリソース編）いかがでしたでしょうか？

　いままでコスト最適化について後回しにしてきた場合、円安というピンチを再検討のチャンスと捉えて見直してみてはいかがでしょうか。本稿が皆さんのAWS利用のコスト最適化に少しでも寄与できれば幸いです。

筆者紹介

沼崎 伸洋（ぬまざき のぶひろ）

株式会社システムシェアード　開発事業部所属。

ここ数年はAWSを利用したシステムの設計、開発、構築を行っています。

仕事以外では、AWSの資格をあと2つでコンプリートできるので制覇に向けて頑張っています！