本番環境でも、常時アクセスが少なく、負荷の予想がしっかりできている場合にはバースト可能なt系インスタンスを使って費用を抑えることもありだ。
RDS
一番安価なリザーブドインスタンス（RI: reserved instance）を買えるdb.t3.microについて検討する1。
db.t3.microはvCPUが2個であり、時間あたり12 CPUクレジットを得られる。
12 CPUクレジット / 2 vCPU / 60 分 = 0.1
だから、このインスタンスタイプのvCPUあたりのベースラインパフォーマンスは0.1 つまり10%だ。
次に、各データベースインスタンスのモニタリングか、CloudWatch MetricsからCPUUtilizationを確認する。
このCPUUtilizationは全vCPUの平均になるようだ。
だからvCPU2個のインスタンスで一方のvCPU使用率が0 %、もう一方が100 %ならば値は50%になるだろう。
CPUUtilizationが上で算出したベースラインパフォーマンス（ここでは10%）を下回っていて、将来にわたっても（RIを買うならどんなに少なくとも1年間は）下回り続けるか確認する。
また、CPUCreditUsageとCPUCreditBalanceを確認し、負荷のスパイクを蓄積されたCPUCreditBalanceで十分カバーできるか、枯渇する恐れがないか確認する。
CPUCreditBalanceが枯渇する状況が続くと追加でバースト用の料金を課金され、かえって高くなってしまう可能性がある。
そのような状況ではより大きなインスタンスタイプもしくは、バーストインスタンスではなく、db.m6g.largeやdb.m5.largeのような定常パフォーマンスインスタンスの利用を検討すべきだ。
よく使いそうなインスタンスタイプの表
| インスタンスタイプ | vCPU | CPU クレジット / 時間 | ベースラインパフォーマンス [%] | メモリ [GiB] |
|---|---|---|---|---|
| db.t3.micro | 2 | 12 | 10 | 1 |
| db.t3.small | 2 | 24 | 20 | 2 |
| db.t3.medium | 2 | 24 | 20 | 4 |
| db.t4g.micro | 2 | 12 | 10 | 1 |
| db.t4g.small | 2 | 24 | 20 | 2 |
参考資料
Amazon CloudWatch メトリクスを使用して Amazon RDS についてより適切な意思決定を行う | Amazon Web Services ブログ
EC2の説明だが、RDSも同様。
バーストパフォーマンスインスタンスに関する主要な概念と定義 - Amazon Elastic Compute Cloud
