2022/06/08 の事。

AWSはここ数年Gravitonプロセッサをプッシュしていますが、同程度のCPU・メモリだとAWS Pricing Calculatorの費用計算上はx86系より確かに安くなるな、ということでAWS東京リージョンのAWS AuroraでGraviton導入してみました。

…いや、しようとしました。
以下はRDSイベントからの抜粋：

Insufficient instance capacity for instance type db.r6g.large in 
availability zone ap-northeast-1c; putting database instance into available

実際はインスタンス容量の不足ということで導入できず。
別の機会ではうまく行ったんですけど。AWS東京リージョンの一部アベイラビリティゾーンでGravitonプロセッサの空きが物理的に足りないんだと想像してます。

つまり、今はクジ運が問われるかもしれない状況。

あくまで一過性かもしれませんが、いつGravitonプロセッサの空きが補充されるかわかりかねるので、現時点だと常にGravitonプロセッサで動かすような運用シナリオは堅牢じゃないのかもしれないですね。

長めのリードタイム、多めのリトライを心がけてインスタンス導入を始めたり、RDSリザーブドインスタンスでGravitonプロセッサ使うタイプが何台欲しいのか事前指定しておくなどが対策として考えられます。

以下詳細。

2022/06/08 時点で、東京リージョン ap-northeast-1 のアベイラビリティゾーン apne1-az1 では、RDSのタイプ db.r6g.large のインスタンス確保が難しそう。14:00〜17:30で11回試行して2回だけ成功。
一方、apne1-az4では5回試行してすべて成功。

一意なアベイラビリティゾーンIDの調べ方：
https://dev.classmethod.jp/articles/use-az-id-for-identify-az-crossing-over-account/

雑感

バージニア北部リージョンのCloudWatchメトリクスの名前空間 AWS/TrustedAdvisor では自アカウントがサービス毎の制限にどれほど近づきつつあるかがメトリクスから判断できるんですが、ここでは流石にアカウントをまたいだリソース状況（例：アベイラビリティゾーンのGravitonプロセッサの空き）を正確に公開するのは不味いんでしょうかね。

AWS APIやサービスに対するメタ情報を提供する口がもっと増えてくれたらなぁと思います。