ロールアウトポリシーの構文と例をアップグレードする - AWS Organizations
考慮事項基本的なポリシー構造ポリシーの構成要素ロールアウトポリシーをアップグレードする例

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

ロールアウトポリシーの構文と例をアップグレードする

アップグレードロールアウトポリシーは、 AWS サービスがリソース全体に自動アップグレードを適用する方法を定義します。ポリシー構文を理解すると、組織のアップグレード要件に合った効果的なポリシーを作成できます。

考慮事項

アップグレードロールアウトポリシーを実装するときは、以下の重要な要素を考慮してください。

  • ポリシー名は組織内で一意でなければならず、明確かつわかりやすいものでなければなりません。ポリシーの目的と範囲を反映する名前を選択します。詳細については、「運用効率の最適化」を参照してください。

  • 広範なデプロイの前にテストが不可欠です。本番稼働用以外の環境で新しいポリシーを最初に検証し、徐々に拡張して目的の動作を確認します。詳細については、「小規模から始めて徐々にスケールする」を参照してください。

  • ポリシーの変更が組織全体に反映されるまでに数時間かかる場合があります。それに応じて実装を計画し、適切なモニタリングが実施されていることを確認します。詳細については、「変更のモニタリングと伝達」を参照してください。

  • JSON 形式は有効で、ポリシーの最大サイズである 5,120 バイト以内である必要があります。要件を満たすと同時に、ポリシー構造をできるだけシンプルに保ちます。

  • 定期的なポリシーレビューは、有効性を維持するのに役立ちます。ポリシーの定期的な評価をスケジュールして、組織のニーズを引き続き満たしていることを確認します。詳細については、「レビュープロセスを確立する」を参照してください。

  • アップグレード順序が割り当てられていないリソースは、デフォルトで「2 番目の」順序になります。デフォルトに依存するのではなく、重要なリソースのアップグレード順序を明示的に設定することを検討してください。詳細については、「ポリシーの変更を効果的に検証する」を参照してください。

  • 手動アップグレードは、ポリシー定義のアップグレード順序よりも優先されます。変更管理プロセスが自動アップグレードシナリオと手動アップグレードシナリオの両方を考慮に入れていることを確認します。詳細については、「レビュープロセスを確立する」を参照してください。

注記

管理アカウントからタグベースのアップグレードロールアウトポリシーを実装する場合、管理アカウントはメンバーアカウントのリソースレベルのタグを直接表示またはアクセスできないことに注意してください。メンバーアカウントが一貫したリソースタグを適用するプロセスを確立し、これらのタグを参照する組織レベルのポリシーを作成することをお勧めします。これにより、リソースレベルのタグ付けと組織ポリシーの適用が適切に調整されます。を使用して、組織全体でリソースタグポリシーにタグが付けられたときに一貫したタグを維持することもできます。

基本的なポリシー構造

アップグレードロールアウトポリシーは、次の主要な要素を含む JSON 構造を使用します。

  • ポリシーメタデータ (バージョン情報など)

  • リソースターゲティングルール

  • アップグレード注文の仕様

  • オプションの例外メッセージ

  • サービス固有の属性

次の例は、基本的なアップグレードロールアウトポリシー構造を示しています。

{
   "upgrade_rollout":{
      "default":{
         "patch_order":{
            "@@assign":"last"
         }
      },
      "tags":{
         "devtag":{
            "tag_values":{
               "tag1":{
                  "patch_order":{
                     "@@assign":"first"
                  }
               },
               "tag2":{
                  "patch_order":{
                     "@@assign":"second"
                  }
               },
               "tag3":{
                  "patch_order":{
                     "@@assign":"last"
                  }
               }
            }
         }
      }
   }
}

ポリシーの構成要素

アップグレードロールアウトポリシーは、リソース間でアップグレードがどのように適用されるかを制御するために連携する 2 つの主要なコンポーネントで構成されます。これらのコンポーネントには、デフォルトの動作とタグベースの上書きの両方の設定オプションが含まれます。これらのコンポーネントがどのように相互作用するかを理解することは、組織のニーズに合わせて効果的なポリシーを作成するのに役立ちます。

デフォルトのパッチ順序の設定

リソース固有のオーバーライドを指定せずにアップグレードロールアウトポリシーを作成すると、すべてのリソースがデフォルトで基本アップグレード順序になります。このデフォルトは、ポリシーの「default」フィールドを使用して設定できます。タグによる明示的なアップグレード順序の割り当てがないリソースは、このデフォルトの順序に従います。

注記

今日のコンソールエクスペリエンスでは、デフォルトの順序を指定する必要があります。

次の例は、タグによって上書きされない限り、デフォルトでアップグレードを最後に受け取るようにすべてのリソースを設定する方法を示しています。このアプローチは、アップグレードサイクルの後半でほとんどのリソースを確実に更新する場合に役立ちます。

"upgrade_rollout": {
    "default": {
        "patch_order": "last"
    }
}

タグによるリソースレベルの上書き

タグを使用して、特定のリソースのデフォルトのアップグレード順序を上書きできます。これにより、どのリソースがどの順序でアップグレードを受け取るかをきめ細かく制御できます。たとえば、環境タイプ、開発ステージ、ワークロードの重要度に基づいて異なるアップグレード順序を割り当てることができます。

次の例は、アップグレードを最初に受信するように開発リソースを設定し、最後に受信するように本番稼働用リソースを設定する方法を示しています。この設定により、開発環境は本番環境に到達する前にアップグレードを検証できます。

"upgrade_rollout": {
    "tags": {
        "environment": {
            "tag_values": {
                "development": {
                    "patch_order": "first"
                },
                "production": {
                    "patch_order": "last"
                }
            }
        }
    }
}

ロールアウトポリシーをアップグレードする例

一般的なアップグレードロールアウトポリシーのシナリオは次のとおりです。

例 1: 開発環境を最初に

この例では、最初にアップグレードを受け取るように開発環境でリソースを設定する方法を示します。「開発」環境タグを使用してリソースをターゲットにすることで、開発環境が新しいアップグレードを最初に受信して検証できるようにします。このパターンは、アップグレードがより重要な環境に到達する前に潜在的な問題を特定するのに役立ちます。

{
    "tags": {
        "environment": {
            "tag_values": {
                "development": {
                    "upgrade_order": "first"
                }
            }
        }
    }
}

例 2: 本番環境の最終

この例では、本番環境がアップグレードを最後に受け取るようにする方法を示します。本番稼働用タグ付きリソースを最終アップグレード順序に明示的に設定することで、本番稼働前の環境で適切なテストを行いながら、本番稼働環境の安定性を維持します。このアプローチは、厳格な変更管理要件を持つ組織にとって特に役立ちます。

{
    "tags": {
        "environment": {
            "tag_values": {
                "production": {
                    "upgrade_order": "last"
                }
            }
        }
    }
}

例 3: タグを使用した複数のアップグレード順序

次の例は、異なる値を持つ単一のタグキーを使用して 3 つのアップグレード順序をすべて指定する方法を示しています。このアプローチは、単一のタグ付けスキームを使用してアップグレード注文を管理する場合に役立ちます。

{
   "upgrade_rollout":{
      "default":{
         "patch_order":{
            "@@assign":"last"
         }
      },
      "tags":{
         "devtag":{
            "tag_values":{
               "tag1":{
                  "patch_order":{
                     "@@assign":"first"
                  }
               },
               "tag2":{
                  "patch_order":{
                     "@@assign":"second"
                  }
               },
               "tag3":{
                  "patch_order":{
                     "@@assign":"last"
                  }
               }
            }
         }
      }
   }
}