AWS検証環境のコスト見直し(後編) | AQ Tech Blog

サムネ出典URL：https://burst.shopify.com/photos/making-a-budget-tracking-finances?q=money

概要

前編ではAWSのコストの把握について説明しました。後編ではコスト削減として以下について紹介させていただきます。

• インスタンス利用料の削減
• ネットワーク構成の見直し
• アカウントのリセット
• アカウントの分割
• 利用リージョンの検討

インスタンス利用料の削減

検証で利用機会の多いEC2/RDSインスタンスの費用については、全体のかなりの割合を占めていたため、以下のような対策を検討しました。

1.必要最小スペックのサーバ構築の徹底

サーバのスペックについては、検証であれば必要最小限のものを利用するように再度周知をしました。特にライセンス利用料が上乗せされるRHELなどはAmazon Linuxと比較しても費用が高額になるため、ソフトウェア要件で指定がない場合を除いて安価なOSSのOSを利用するように周知しました。

検証内容にもよりますが、RDS/AuroraについてもマルチAZではなくシングルAZで利用するだけでコストは半分になるかと思います。

作成できるインスタンスタイプをIAMポリシーで絞るという意見も出ましたが、検証作業に支障が出ることがあるため採用を見送りました。

参考：特定のインスタンスタイプ以外のEC2 の起動を禁止するポリシー例 | Nijot Tech Blog
https://blog.nijot.com/etc/restrected-ec2-instance-types-policy/

2.Lambda/EventBridgeを使ったサーバの強制停止

利用していないインスタンスは停止/削除するように周知はしていたものの、やはり停止忘れが頻発しました。また、RDS/Auroraについては停止したとしても7日経過すると自動的に起動してしまいます。そこで毎日一定時刻になると利用していないインスタンスを全て停止するようにしました。

ブログなどを参照すると「Stop」「AutoStop」タグが付いているインスタンスについては停止するLambdaの記事は散見されたものの、タグを付け忘れる可能性が高いという意見があがりました。そのため「NoStop」タグ(停止してほしくないフラグ)が付いていないインスタンスを全て停止するLambdaをEventBridgeで定期実行するという運用になりました。(そもそも夜間もサーバを起動中にする必要がある検証を行うケースが少ないので)

EC2インスタンスの意図しない停止・終了するアクションから保護するStop Protection 機能が最近追加されたので、この機能を有効化していないEC2インスタンスは全て停止するという運用も可能です。

参考：Amazon EC2 で、意図しない停止アクションからインスタンスを保護することが可能に
https://aws.amazon.com/jp/about-aws/whats-new/2022/05/amazon-ec2-enables-protect-instances-unintentional-stop-actions/
参考：Lambda を使用して、EC2 インスタンスを一定の間隔で停止および起動する
https://aws.amazon.com/jp/premiumsupport/knowledge-center/start-stop-lambda-eventbridge/

3.割引プランの検討

インスタンスの値引き方法として以下の2つを検討しました。

・Savings Plans

Savings Plansは1 年または 3 年の期間で特定の時間当たりの使用料金を契約することで、オンデマンドと比較して最大72％のコストを削減できます。インスタンスの割引が適用できるSavings Plansには、Compute Savings Plans、EC2 Instance Savings Plansがあります。

参考：Savings Plans – アマゾン ウェブ サービス
https://aws.amazon.com/jp/savingsplans/

考慮する点としては以下の通りです。

• AWS Organizationsで管理されているAWSアカウントについてはデフォルトで全てのアカウントにSavings Plansの共有されてしまいます。例えば、アカウントAで購入したSavings Plansを使い切らなかった場合、アカウントBに残りの割引が適用されます。Savings Plansの共有を特定のAWSアカウントのみ有効化/無効化することも可能です。

• Savings Plansの対象に含まれていないリソースを頻繁に利用するようであればリザーブドインスタンスを購入する必要があります。

上記二点と、検証環境はインスタンスのコストが流動的で予測を立てるのが難しいという理由によりSavings Plansの適用は見送りました。

参考：共有リザーブドインスタンスと Savings Plans の割引の有効化 - AWS 請求
https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/ri-turn-on-process.html

・スポットインスタンス

スポットインスタンスはAZ内のEC2の空きキャパシティを活用し、オンデマンドインスタンスと比較して最大 90%のコスト削減が可能です。上限料金をリクエストして使用し、上限料金を超えた場合か、AZに利用可能なキャパシティがなくなった場合、強制的に中断されます。

参考：Amazon EC2 スポットインスタンス | AWS
https://aws.amazon.com/jp/ec2/spot/
参考：スポットインスタンスアドバイザー | AWS
https://aws.amazon.com/jp/ec2/spot/instance-advisor/

スポットインスタンスのデメリットとして、以前は終了しかできない点がありましたが、設定時に「永続的リクエスト」を有効にすることで「停止」することも可能になり長期の検証でも活用しやすくなりました。

参考：オンデマンドインスタンスと同様に、Amazon EC2 スポットインスタンスを停止および開始可能に
https://aws.amazon.com/jp/about-aws/whats-new/2020/01/amazon-ec2-spot-instances-stopped-started-similar-to-on-demand-instances/

【EC2インスタンスの設定画面】

ただし、この「永続的リクエスト」を有効にした状態でインスタンスを終了しても、リクエストの有効期限内だとゾンビインスタンスが起動してきてしまい、結局無駄なコストが発生するため注意が必要です。

「永続的リクエスト」を有効にしたインスタンスを終了したい場合は、スポットリクエストの管理画面から「リクエストをキャンセル」する必要があります。

【スポットリクエストの管理画面】

スポットインスタンスはインスタンスの割引率も高く、Savings Plansのように年間利用料をコミットする必要がないためコスト削減には非常に有効的な手段です。ただし、予期せぬ中断が発生したり、停止するためにも仕様を理解する必要があるため、それらを考慮した上で活用するのは良いかと思います。

参考：Amazon EC2 だけじゃない！最⾼のコスト効率を手に入れるためのスポットインスタンス使いこなし術
https://pages.awscloud.com/rs/112-TZM-766/images/AWS-27_AWS_Summit_Online_2020_CMP01.pdf

ネットワーク構成の見直し

弊社の検証環境は、各自でVPC/サブネット/ルートテーブルを作成するという運用になっていました。ネットワーク関連のリソースが大量に存在してもコスト的にはそこまで影響はないのですが、この時の一番の問題はNATゲートウェイのコストについてでした。
NATゲートウェイは削除しない限り課金され続け、1台当たり月額約44ドル+処理データ転送量が課金されるため、NATゲートウェイが乱立するとコストの高騰に繋がります。

参考：料金 - Amazon VPC | AWS
https://aws.amazon.com/jp/vpc/pricing/

そのため検証環境用のVPC/Subnetを1つ作成しNATゲートウェイを共有しようと考えましたが、個々の検証に支障をきたす可能性があるためこの案は見送り、利用していないNATゲートウェイについては削除するというルールにとどめることになりました。
ただ、NATゲートウェイを1台起動し続けていると年間500ドル近いコストが発生してしまいます。NAT Gatewayを使わずコスト削減を目的にするのであれば、以下のような方法もあります。

1.パブリックサブネットでインスタンスを起動

プライベートサブネットではなくパブリックサブネットにインスタンスを起動し、EIPを付与して外部と通信を行えるようにしても良いかもしれません。ただし、外部からアクセスできる状態になるため、必要最低限の通信のみ許可するようセキュリティグループやネットワークACLを設定する必要があります。

2.VPCエンドポイントを活用

S3やDynamo DBなどAWSリソースへアクセスすることだけが目的であればVPCエンドポイントを利用した方が費用が安く済むこともあります。
例えばAmazon LinuxのyumリポジトリはS3に存在するので、プライベートサブネットにあるAmazon Linuxにyumでパッケージをインストール/アップデートするだけであれば、S3 VPCゲートウェイエンドポイントを作成し、ルートテーブルに関連付ければ、NATゲートウェイを介さずとも無料でyumを実行することも可能です。(EPELなどAmazon Linuxリポジトリに存在しないパッケージは対象外です。)

参考：インターネットにアクセスせずに自分の AL1 または AL2 EC2 インスタンスで yum を更新する
https://aws.amazon.com/jp/premiumsupport/knowledge-center/ec2-al1-al2-update-yum-without-internet/

アカウントのリセット

現在利用中のアカウントは4年以上運用しており、利用していないと思われるリソースも多々存在しました。この不要なリソースの中でElastic IPなど課金が発生し続けているリソースが積み重なってコストを圧迫しているところがあったので、新しいアカウントをリセットして新規に作成するという案もありました。
ただ、現在お客様の検証を行っている環境や再度利用する可能性のある環境もあったので、アカウントのリセットは見送りました。

ちなみにAWSアカウント内のリソースを一括削除できるaws-nukeというツールも存在します。リソースの指定や特定条件でフィルター除外した削除を行うことも可能なので、アカウントを継続利用したい場合や棚卸の際にリソースを一括削除したい場合には有効かもしれません。
ただし設定を誤ると必要なリソースを削除してしまったり、IAM周りのリソースを削除してしまうとアカウントにログインできなくなる危険性もあるので、必要なリソースが削除されると影響が大きいアカウントでは利用しないようにしてください。また、必ずdry-runを実行して、対象を確認してから実行するようにしてください。

参考：rebuy-de/aws-nuke: Nuke a whole AWS account and delete all its resources.
https://github.com/rebuy-de/aws-nuke

参考：AWSアカウントのクリーンアップに役立つaws-nukeの紹介と注意点 | DevelopersIO
https://dev.classmethod.jp/articles/aws_nuke_intro/

アカウントの分割

1つの検証用AWSアカウントをメンバーで共有していましたが、それでは個人毎のコストを正確に把握することが難しいため、各メンバーにAWS Organizationsでメンバーアカウントを割り当てるという案もありました。

ここで問題になったのは以下の2点です。

1.AWSから定期的に提供されるクレジットをどのアカウントに割り当てるか

クレジットとはAPNパートナー更新時やAWS認定資格取得時などにAWSから提供される、対象サービスのコスト割引に使用できるクーポンのようなものです。

特に、弊社が認定を受けているアドバンスドコンサルティングパートナーの更新の場合、2022年時点で年間5,000ドルのクレジットを受け取ることができ、非常に大きな恩恵を受けています。

ただしクレジットは以下の優先順位でアカウントに紐づけられるため、個別にメンバーアカウントを作成する場合はクレジットの割り当て方法を検討する必要がありました。

1. クレジットを所有するアカウント
2. 支出が最も高いアカウント
3. そのアカウント内で支出が最も高いサービス

参考：AWS クレジット - AWS 請求
https://docs.aws.amazon.com/ja_jp/awsaccountbilling/latest/aboutv2/useconsolidatedbilling-credits.html

2.AWS Organizationsの管理を誰が行うのか

現在、弊社では複数のAWSアカウントをAWS Organizationsで管理しており、アカウントやユーザー作成・削除の運用については管理者を立てています。検証用のメンバーアカウントの管理まで現在のOrganizations管理者に任せるのは負荷も上がるため、別途管理用アカウント(親)を作成する必要がありましたが、結局は別の管理者を立てる必要があり、運用も別途検討する必要が出てきました。

各メンバーのコストを把握するためだけという目的にしては検討することが多くなってしまったため、メンバーアカウントを割り当てるという案は見送りになりました。

利用リージョンの検討

弊社のメンバーの多くは、東京リージョンで検証を行っていましたが、他のリージョンの費用を確認してみると、概ねバージニア北部(us-east-1)がリソースの利用料としては一番安価にAWSサービスを利用できることが分かりました。

参考までに東京リージョンとバージニア北部リージョンで同スペックのRDSのコストを比較すると、約3分の2程度の費用になります。

学習用で利用する場合はバージニア北部で統一する方針で問題ないと考えましたが、東京リージョンを利用しているエンドユーザー様向けの事前検証は以下の点を考慮する必要がありました。

• バージニア北部はAWSサービスが最もリリースされているリージョンのため、東京リージョン(ap-northeast-1)ではリリースされていないサービスや機能が存在する場合がある。
• 日本で利用する限り、レイテンシーに関してはバージニア北部の方が大きくなるので、検証に支障をきたす場合がある。

上記から、可能であればバージニア北部で検証を行う程度としました。

ただ、コスト削減という観点では非常に有効な方法だと思いますので、学習用途などユーザー影響のない検証であればバージニア北部でもよいのではないかと思います。

実施結果

検討を行った結果、以下の対策を実施しました。

• コスト高騰の検知
• 利用状況の把握
• インスタンス利用料の削減

結果、直近の利用料は1,000ドル前後に落ち着いてきました。

まとめ

後編ではコスト削減対策について紹介させていただきました。

色々と対策を検討しましたが、結局一番大事なことは継続的にチェックを行う習慣をつけることかと思います。

検証環境のように日々リソースの作成・削除が繰り返されるような環境だと、どうしても削除忘れは発生してしまうので、定期的に棚卸を行うのはもちろん、なるべく早くコストの高騰に気づき、対処することが重要かと思います。

参考情報

参考：コスト最適化の柱 － AWS Well-Architected フレームワーク - コスト最適化の柱
https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/cost-optimization-pillar/welcome.html