![[アップデート] AWS Organizations に AWS サービスの自動アップグレードに優先順位を設定できる「アップグレードロールアウトポリシー」が追加されました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-2eddd7f989fa67416ea2d27b4223cc32/8f5b157eb82ee11cc288225119e0c290/aws-organizations?w=3840&fm=webp)
[アップデート] AWS Organizations に AWS サービスの自動アップグレードに優先順位を設定できる「アップグレードロールアウトポリシー」が追加されました
いわさです。
AWS Organizations では AWS Organizations のポリシーという機能を使うことで組織内の AWS アカウントにベースラインを設定して統制・管理することができます。
これまでも様々なポリシーがあって、よく使われるサービスコントロールポリシー（SCP）やリソースコントロールポリシー（RCP）などを始め、他にも組織のバックアップポリシーや AI サービスをオプトアウトするポリシーなど様々なものが良いされています。
先日のアップデートでここに新しいポリシー「アップグレードロールアウトポリシー」が追加されました。
アップグレードロールアウトポリシーを使うことで、複数の AWS サービスでの自動アップグレードの段階的な適用方法を管理することができます。
本日時点では Amazon RDS / Aurora の自動アップグレードのみがサポートされていまして、ポリシーの構成を行ってみましたので紹介します。
アップグレードロールアウトポリシーの作成と適用
AWS Organizations コンソールからポリシーメニューを開きましょう。
一番下に「アップグレードロールアウトポリシー」が追加されていました。
デフォルトは無効化されているので、他のポリシーと同様に有効化します。
有効化後はポリシーの一覧が管理できるようになりますので、ここからポリシーを作成しましょう。
後ほど試しますが、アップグレードロールアウトポリシー自体の無効化もここから可能です。
アップグレードロールアウトポリシーの作成に必要な情報ですが、ポリシー名とあとは下部のビジュアルエディタで設定できるポリシーの順序とリソースです。
何を設定するかというとfirst、second、lastの３つから選択を行います。
今回のアップデートでは Amazon RDS と Amazon Aurora がこのロールアウトポリシーの対象なのですが、この順序はマイナーバージョンアップグレードがロールアウトされる順番を示しています。
アップグレードロールアウトポリシーの挙動については以下にも記載されています。
大前提になりますが、このアップグレードロールアウトポリシーが適用されるのは自動マイナーバージョンアップグレードを有効化したリソースのみが対象となります。
組織に対してこの自動マイナーバージョンアップグレードの有効/無効を統合管理する機能ではありません。自動マイナーバージョンが適用されるリソースの中でさらに適用順序を設定できるというものになります。
3段階の順序を設定することができて、firstが設定されているリソースから最初にマイナーバージョンが利用できるようになり、その後サービスごとに固有の一定期間後にsecondが設定されているリソースでもマイナーバージョンが自動適用されるようになります。
公式ドキュメントによるとfirstとsecondの間の待機期間は通常約 1 週間であると記載されています。[1]
その後さらに一定期間を経てlastが設定されているリソースにもマイナーバージョンが自動適用されます。
このように段階的な期間を設けて自動適用することで、ビジネスインパクトのない環境で早期にマイナーバージョンを自動適用して評価をし、問題を発見した際にはその後の順序のリソースには自動適用を中止することができるようになります。マイナーバージョンの自動適用をしたいが、リスクヘッジするための期間を少し設けれるような使い方が出来そうです。
このロールアウト順序ですが、ロールアウトポリシーを使わなかった場合でも概念としてすでに導入されているようでして、何もロールアウトポリシーが設定されていない場合はsecondとして動作するようです。
そしてこのロールアウトポリシーで設定できるのは組織に適用するロールアウト順序のデフォルトを何にするか、あるいは次のようにタグベースルールでロールアウト順序を個別に設定することもできます。
開発環境 OU ではfirstで適用するとか、あるいは混在している OU でもenvironmentタグなどをリソースに割り当てることで開発環境リソースなのか本番環境リソースなのかなどを判断して順序を設定できそうです。
今回は上記のようにデフォルトをfirstにしつつ、ステージング環境リソースの場合はsecond、本番環境リソースの場合はlastという形でよくありそうなポリシー構成にしてみました。
ロールアウトポリシーを作成後、組織にアタッチします。
アタッチ対象は他のポリシーと同じで、OU あるいは AWS アカウントに対して指定可能です。
アップグレードロールアウトポリシーが適用されている RDS インスタンス
今回は OU にロールアウトポリシーを適用してみました。
ポリシー適用範囲の AWS アカウント上で Amazon RDS for MySQL インスタンスを作成して試してみます。
前提としてマイナーバージョン自動アップグレードを有効化する必要があります。
タグなしの開発環境を想定したリソースと、タグありの本番環境を想定したリソースを作成してみました。
今回のアップデートで RDS コンソールのインスタンス一覧上に「ロールアウト順序のアップグレード」というカラムが追加されていました。ここにこのインスタンスに適用されたロールアウト順序を確認することができますね。
期待どおりで、開発環境の場合はfirst、本番環境の場合はlastが設定されています。
実際のマイナーバージョン適用の様子は今日は確認できないのですが、これでまずはじめに開発環境だけ自動適用され、数週間後に本番環境にも自動適用される形になりそうです。
なお、Amazon RDS for Oracle に関してのみ、2026 年 1 月以降のマイナーバージョンから対象となるみたいです。おそらくパッチごとにfirstがいつでとか設定されているのかな。
アップグレードロールアウトポリシーを無効化する
また、アップグレードロールアウトポリシーは適用されている状態からそのまま無効化もできます。
無効化した時に既存のデータベースにどのような影響がでるのか見てみます。
AWS Organizations コンソールのポリシーメニューからアップグレードポリシーを無効化してみましょう。
対象アカウント上のインスタンスのロールアウト順序がsecondになりました。なるほどね。
さいごに
本日は AWS Organizations に AWS サービスの自動アップグレードに優先順位を設定できる「アップグレードロールアウトポリシー」が追加されたので試してみました。
マイナーバージョン自動アップグレードが有効化されていることを前提に、さらにその中で期間的な順序を設定できるポリシーということで覚えておきましょう。
ポリシーを設定しなかった場合はsecondで動作するので、標準よりも早くしたいあるいは遅くしたい場合はアップグレードロールアウトポリシーを使ってfirstあるいはlastに設定するのが良いですね。
今回のアップデートでは Amazon RDS と Aurora だけがサポート対象ですが、今後他の自動アップグレードをサポートしているサービスにも展開されそうな作りです。
