こんにちは。株式会社ペライチのインフラエンジニア西野です。
さて、皆さんはご自身の会社で利用しているシステム基盤(AWS や GCP など)にかかる月々のコストを把握していますか？
正直、以前は把握していませんでした。しかし最近、AWS のコストを確認する機会が増えたことで、これまでの反省も込めて本記事を書くことにしました。
この記事では、特に検証環境における無駄なコストを削減するための 3 つのポイントに焦点を当てます。
目次
- 複数台配置(Multi-AZ)や過剰なインスタンスサイズ
- ログなどの保存期間
- 24 時間稼働の必要性
- まとめ
1. 複数台配置(Multi-AZ)や過剰なインスタンスサイズ
本番環境を模倣した検証環境にかかるコストを把握していますか？
検証環境、特にステージング環境を本番と同じ構成で構築することは一般的です。
しかし、構成だけでなく、インスタンスサイズや冗長構成といった可用性までを検証環境で常に再現する必要があるのでしょうか。
Multi-AZ とは？
マルチ AZ（Multi-AZ）構成とは、複数のアベイラビリティーゾーン（AZ）にシステムを分散配置することで、可用性と耐障害性を高める方法です。ひとつの AZ が障害で停止しても、別の AZ のシステムが稼働し続けるため、サービスの可用性が向上します。
個人的には、機能検証や開発中のテストが主目的であれば、小さなインスタンス 1 台でも十分だと考えています。コストや運用の観点からも、できる限りミニマルな構成が望ましいといえます。
たとえば、Aurora RDS のオンデマンド利用では時間あたり下記のコストが発生します。
- インスタンスサイズ：db.r5.4xlarge
| 項目 | 料金 |
|---|---|
| 時間 | $2.80 |
| ストレージ | $0.12 |
| リクエスト | $0.24 |
では、上記の RDS を複数台構成(Multi-AZ)にしたときの月額費用はどうなるでしょうか。
- 2 台：24 時間稼働
- $2.80 × 720 時間(月間) × 2 台 = $4,032
ひと月で 60 万円近くのコストが掛かります。本番環境と同等にそろえるためだけに、検証環境へこれだけのコストをかけるのは妥当なのでしょうか？
検証環境は本番環境を模倣せず、複数台構成の必要性、適切なインスタンスサイズを見極めることが大切です。
参考
2. ログなどの保存期間
検証環境のログ保存期間やECRへのイメージ保存数は意識していますか？
CloudWatch Logs や S3、ECR は、ログデータやコンテナイメージの保存に利用される代表的なサービスです。これらは一見コストが安価に見えますが、蓄積されるデータ量によってはじわじわとコストが増加していきます。
保存期間やイメージの保持数を意識せずにデフォルト設定のまま使い続けると、データが無制限に蓄積され、結果的に予想以上の料金が発生するリスクもあります。
たとえば、1 日 10GB の出力があった場合に 3 年後には下記のコストが発生します。
| 項目 | 料金 |
|---|---|
| 保存ストレージ | $0.03 / GB/月 |
| データ取り込み | $0.50 / GB（初回取り込み時のみ） |
保存データ量（3 年間）：10GB × 30 日 × 36 ヵ月 = 10,800GB（約 10.8TB）
3 年後のデータ量（ひと月）：10.8TB × $0.03 = $324。
3 年後にはひと月で 3 万円程のコストが発生します。適切な保存期間を設定せず、無期限にしておくと気付かぬ間に予想以上のコストがかかります。
では、どのようにして保存数や保存期間を設定するのか。
-
CloudWatch Logs の保存期間設定
マネジメントコンソールからでも、AWS CLI のどちからでも設定が可能
アクセス頻度に応じて 30 日 /90 日 /180 日に設定をします。 -
Amazon S3 のライフサイクル設定
マネジメントコンソールからでも、AWS CLI のどちからでも設定が可能
例）ログファイルを 90 日後 Glacier Deep Archive に移動、365 日後に削除など。 -
Amazon ECR のライフサイクルポリシー設定
マネジメントコンソールからでも、AWS CLI のどちからでも設定が可能
例）latest タグのイメージを 10 個以上残さないや、特定のタグを残すなど。
検証環境はログの保存期間やイメージの保存数など、適切な保存期間、保存数の設定をしましょう。
参考
3. 24時間稼働の必要性
AWS では基本、従量課金＝使った分だけ支払う形式になっており、稼働時間やデータ通信量などさまざまな形で課金されます。
本番環境は 24 時間稼働が大前提ですが、検証環境も 24 時間稼働させる必要があるでしょうか。
例）Aurora RDS(t4g.medium)を 24 時間稼働させた場合
$0.133 * 720h = $95.76(約¥14,395)
上記の RDS を 24 時間稼働させると月々で 1 万 4 千円ほど掛かります。
ですが、では、24 時間稼働させずに 22 時〜 7 時の間は停止させるとどうなるでしょうか。
$0.133 * 330h(土日除く) = $43.89(約¥6,595)
深夜帯の間だけやめるだけでも費用は格段に安くなることが分かります。
ケーススタディ：どうしても24時間稼働が必要な検証環境の場合
3-1. どうしても稼働時間を減らせない場合の対策
RI(Reserved Instances、予約インスタンス)および SP(Savings Plans、節約プラン)は、AWS が提供するコスト削減プランです。
料金を前払いしてコミットすることで割り引きが適用され、お得に利用できます（弊社では本番環境の一部で利用しています）。
| 項目 | Reserved Instances (RI) | Savings Plans (SP) |
|---|---|---|
| 適用対象 | EC2, RDSなど | EC2, Fargate, Lambda など |
| 柔軟性 | 低い（サイズ・リージョン固定） | 高い（インスタンスタイプ変更可） |
| 契約期間 | 1年または3年 | 1年または3年 |
| 割り引き率 | 最大72% | 最大66% |
たとえば、Aurora RDS（RI で購入した場合）。
RI で購入した場合：1 台/年 $710
オンデマンドの場合：月 $95 * 12 = 1 台/年 $1,140
※ RI の価格は 2025 年 5 月時点、東京リージョンでの全額前払いを想定。
参考
Savings Plan
Reserved Instance(EC2)
Reserved Instance(RDS)
問題解決か🤔
3-2. RI/SPのデメリット
制限の詳細は上記の参考資料を確認してください。ここでは代表的なものを取り上げます。
- RDS は Reserved Instance のみ
- Reserved Instance は途中でインスタンスタイプを変更できず、柔軟な計画変更ができない
- Savings Plans は RI に比べ、柔軟性は上がるが対象サービスが少ない
- 前払いをすると割り引き額が大きくなるが、一度に大きな金額が掛かり、インスタンスタイプなどを誤って購入してしまってもキャンセルができない
※RI/SPは前払い無も選択可能ですが、割り引き率が低くなります。
個人的には 4 が心理的に重くのしかかってきました。
RI/SPを利用せずに少しでも安く済ませる方法はないのか。
上記でも、少し記載していますが、休日・夜間帯の時間は RDS や EC2、ECS を停止することで、料金を抑えることが可能です。
たとえば、ECS Fargate の Savings Plans を 1 年前払いした場合の割り引き率は 20% ですが、稼働率を 80% 以下に下げた方が SP を購入するより安くなります。
では、実際にどのように作ったのか？
これは、コストの話第2弾で書きますので、乞うご期待！
4. まとめ
本記事では、AWS を使った検証環境におけるコスト削減で 3 つのポイントを考えました。
- Multi-AZ構成を再考する: 本番環境の構成をそのまま模倣せず、本当に必要な台数とインスタンスサイズを見極めましょう。
- ログやイメージの管理: 保存期間や保存数に明確な上限を設定し、長期間にわたる不要なコストの発生を防ぎましょう。
- 稼働時間の最適化: 本当に 24 時間稼働が必要か考え、不要なら自動停止で使用時間帯のみに稼働させるしくみを導入しましょう。
本記事を通じて、日々何気なく使っている検証環境やインフラリソースに対するコスト意識を少しでも見直すきっかけ、今後の運用の中で「本当に必要なリソースとは何か？」をあらためて考える一助となれば幸いです。
Discussion