ある企業は、社内向けの業務分析アプリケーションを Amazon RDS for PostgreSQL（db.r6g.xlarge、Multi-AZ）上で常時稼働させています。利用は平日の日中に集中し、夜間と週末はほぼアイ

Question

ある企業は、社内向けの業務分析アプリケーションを Amazon RDS for PostgreSQL（db.r6g.xlarge、Multi-AZ）上で常時稼働させています。利用は平日の日中に集中し、夜間と週末はほぼアイドル状態です。日中の負荷も予測が難しく、突発的に急増することがあります。PostgreSQL 互換を維持しつつ、可用性を損なわずに最小の運用負荷でコストを最適化したいと考えています。最も適切な構成はどれですか。

Accepted Answer

正解: Aurora PostgreSQL 互換の Serverless v2 へ移行し、最小・最大 ACU を設定して負荷に応じて自動的にスケールさせる。Aurora Serverless v2 は ACU(Aurora Capacity Unit)単位で需要に応じて自動的かつ細かく容量をスケールし、アイドル時には最小 ACU まで縮小するため、夜間・週末に無駄な容量コストが発生しません。突発的な負荷急増にも自動追従し、PostgreSQL 互換と Multi-AZ 構成による高可用性を維持したまま運用負荷を最小化できます。

選択肢の RDS Single-AZ + 手動停止は、可用性が低下するうえに RDS の停止は最長 7 日で自動再起動され、停止/起動の手作業も発生するため運用負荷とコスト両面で不適切です。
選択肢の RDS ストレージ Auto Scaling はストレージ容量のみを拡張する機能でコンピューティング費用は削減できず、リードレプリカもアイドル時の課金を減らせません。
選択肢の Aurora Provisioned + リザーブドインスタンスは常時一定容量分を前払いするため、アイドル時間が長くスパイクの大きいワークロードでは容量を無駄に支払うことになります。

Answer

RDS for PostgreSQL を Single-AZ に変更し、夜間と週末はインスタンスを手動で停止して費用を抑える — Single-AZ 化は可用性を損ない、RDS の停止は最長 7 日で自動再起動されるため恒常的な節約にならず、手動の停止/起動操作も発生します。可用性と運用負荷の要件をいずれも満たせません。

Answer

RDS for PostgreSQL にストレージ Auto Scaling を設定し、需要に応じてリードレプリカを増減させる — ストレージ Auto Scaling はストレージ容量を拡張する機能でコンピューティング費用は削減できません。リードレプリカもライターのアイドル課金を減らせず、増減の運用も負荷となるため要件に合致しません。

Answer

Aurora PostgreSQL 互換の Provisioned クラスターへ移行し、1 年のリザーブドインスタンスを購入する — Provisioned クラスター + リザーブドインスタンスは常時一定の容量を前払いで確保します。アイドル時間が長く負荷が読みにくいワークロードでは使われない容量分まで支払うため、コスト最適化になりません。

解説

解説