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

# ロールアウトポリシーをアップグレードする
<a name="orgs_manage_policies_upgrade_rollout"></a>

AWS Organizations アップグレードロールアウトポリシーを使用すると、組織内の複数の AWS リソースとアカウント間で自動アップグレードを一元管理し、ずらすことができます。これらのポリシーを使用すると、リソースがアップグレードを受け取る順序を定義し、本番環境に到達する前に、重要度の低い環境で変更が検証されるようにできます。

今日の複雑なクラウド環境では、多数のリソースとアカウントのアップグレードを管理するのは難しい場合があります。アップグレードロールアウトポリシーは、アップグレードを実装するための体系的なアプローチを提供することで、この課題に対処します。これらのポリシーを使用することで、アップグレードプロセスを組織の変更管理プラクティスに合わせて調整し、リスクを軽減し、運用効率を向上させることができます。

アップグレードロールアウトポリシーは、 の階層構造を活用して AWS Organizations 、組織全体または特定の組織単位 (OUs。この統合により、アップグレードを大規模に管理できるため、手動調整やカスタムオートメーションスクリプトが不要になります。

## 主な特徴と利点
<a name="orgs_manage_policies_upgrade_features_benefits"></a>

アップグレードロールアウトポリシーは、アップグレードを管理するための包括的な機能を提供すると同時に、複数のアカウントと環境にわたってリソースを管理する組織に多大な利点を提供します。次の表は、主要な機能とそれに関連する利点の概要を示しています。


**アップグレードロールアウトポリシーの機能と利点**  
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_manage_policies_upgrade_rollout.html)

ポリシーの継承の詳細については、「」を参照してください[管理ポリシーの継承を理解する](orgs_manage_policies_inheritance_mgmt.md)。

## アップグレードロールアウトポリシーとは
<a name="orgs_manage_policies_upgrade_rollout_what_are"></a>

アップグレードロールアウトポリシーは、 AWS リソースに自動アップグレードを適用する方法とタイミングを決定する一連のルールです。これらのポリシーにより、通常、開発、テスト、本番環境に合わせて、リソースに異なるアップグレード順序を指定できます。これにより、アップグレードが最初に重要度の低いシステムに適用され、本番環境のワークロードに影響を与える前に問題を特定して対処できます。

ポリシーは、First、Second、Last の 3 つのアップグレード順序をサポートしています。これらの注文では、アップグレードに対する段階的なアプローチが作成され、最初に「First」として指定されたリソースがアップグレードを受け取り、次に待機期間の後に「Second」、次に別の待機期間の後に「Last」と指定されます。このずらされたアプローチにより、より重要なシステムに進む前に、各段階でアップグレードを検証する時間を確保できます。

アップグレードロールアウトポリシーは、複雑なマルチアカウント構造を持つ組織や、厳格な変更管理要件を持つ組織にとって特に重要です。これらはup-to-dateシステムを維持し、重要なサービスのアップグレード関連の中断のリスクを最小限に抑えることのバランスを提供します。

## アップグレードロールアウトポリシーの仕組み
<a name="orgs_manage_policies_upgrade_rollout_how_work"></a>

アップグレードロールアウトポリシーは、既存の AWS インフラストラクチャやプロセスとシームレスに統合されます。アップグレードロールアウトポリシーを作成して組織単位にアタッチすると、その OU 内のすべてのアカウントに適用されます。その後、リソースタグまたはパッチ順序を使用して、どのリソースをどの順序でアップグレードするかを指定できます。

サポートされている AWS サービスがアップグレードをリリースすると、アップグレードのロールアウトポリシーを参照して、リソースがアップグレードを受け取る順序を決定します。サービスは最初に、設定されたメンテナンスウィンドウ中に「First」とマークされたリソースにアップグレードを適用します。サービス固有の待機期間、通常は約 1 週間後、「Second」とマークされたリソースがアップグレードの対象となります。最後に、別の待機期間が過ぎると、「Last」とマークされたリソースがアップグレードを受け取ります。

このプロセスにより、組織全体で制御された予測可能な方法でアップグレードが適用されます。これにより、各段階でアップグレードの影響をモニタリングし、変更が最も重要な環境に到達する前に必要に応じて修正措置を講じることができます。このプロセスを自動化することで、アップグレードの管理に伴う運用上のオーバーヘッドが軽減されると同時に、 AWS リソースの安定性とセキュリティを維持するために必要な制御と可視性が得られます。

## 用語
<a name="orgs_manage_policies_upgrade_syntax_terminology"></a>

アップグレードロールアウトポリシーを使用する際に理解しておくべき重要な用語を次に示します。


**ロールアウトポリシーの条件をアップグレードする**  

| 用語 | 定義 | 
| --- | --- | 
| アクティブな日付 | AmVU が「保留中のメンテナンスアクションの説明」 API に表示され、アプリケーションで使用できるようになった日付。 | 
| AmVU (自動マイナーバージョンアップグレード) | データベースエンジンのマイナーバージョンの自動アップグレードプロセス。 | 
| 有効なポリシー | 継承されたポリシーと直接アタッチされたポリシーをすべて考慮した後、アカウントまたはリソースに適用されるルールの最後のセット。 | 
| メンテナンスウィンドウ | リソースに自動アップグレードを適用できる定期的な期間。アップグレードロールアウトポリシーは、これらの設定されたメンテナンスウィンドウ内で機能します。 | 
| 組織単位 (OU) | 組織内の AWS アカウントのコンテナ。アップグレードロールアウトポリシーを OU レベルでアタッチして、その中のすべてのアカウントに影響を与えることができます。 | 
| パッチの順序 | リソースがアップグレードを受け取るシーケンス (First、Second、Last)。 | 
| ポリシーターゲット | アップグレードロールアウトポリシーが適用される範囲。組織全体、特定の OUs、または個々のアカウントです。 | 
| リソースタグ | ポリシー内の特定のアップグレード順序に従うリソースを識別するために使用できるキーと値のペア。 | 
| スケジュールウィンドウ | 特定のパッチ注文のリソースがアップグレードを受け取る期間。 | 
| サービス固有の待機期間 | 異なるアップグレード順序のリソースをアップグレードするまでの指定された時間間隔。この期間は、 AWS サービスとアップグレードタイプによって異なります。 | 
| アップグレード順序 | リソースが他のリソースに対するアップグレードをいつ受け取るかを決定する指定。First、Second、Last のいずれかに設定できます。 | 
| ロールアウトポリシーのアップグレード | リソース間でアップグレードスケジュールを管理するために使用される AWS Organizations ポリシータイプ。 | 

## アップグレードロールアウトポリシーのユースケース
<a name="orgs_manage_policies_upgrade_rollout_use_cases"></a>

さまざまなサイズや業界の組織は、アップグレードのロールアウトポリシーの恩恵を受けることができます。以下の架空のシナリオは、一般的なアップグレード管理の課題と、アップグレードロールアウトポリシーが効率的なソリューションを提供する方法を示しています。これらの例は一般的なカスタマーエクスペリエンスに基づいていますが、主な利点と実装パターンを強調するために簡略化されています。

多くの組織は同様の課題に直面しています。本番環境のリスクを最小限に抑えながら、リソースを最新バージョンup-to-dateに更新する必要があります。一元化されたポリシーベースのアプローチがない場合、チームは多くの場合、手動プロセスや複雑な自動化スクリプトを使用します。次の例は、アップグレードロールアウトポリシーを使用して 2 つの異なる組織が同様の課題を解決する方法を示しています。

### ユースケースの例: Global Financial Services Company
<a name="orgs_manage_policies_upgrade_rollout_use_case_financial"></a>

ある金融サービス会社は、複数の AWS アカウントで数百の Aurora PostgreSQL データベースを運用しています。アップグレードのロールアウトポリシーの前に、DevOps チームは毎月数日間データベースのアップグレードを手動で調整し、本番環境に到達する前に開発環境で変更がテストされたことを確認しました。アップグレードロールアウトポリシーを実装することで、次のことが可能になります。
+ アップグレード順序「First」でタグ付けされた開発データベース
+ アップグレード順序「Second」に割り当てる QA データベース
+ アップグレード順序「最終」として指定された本番データベース
+ アップグレードの調整を数日から数分に短縮
+ 下位環境での変更を最初に自動的に検証する
+ 変更管理要件への準拠を維持

### ユースケースの例: IoT Device Platform Provider
<a name="orgs_manage_policies_upgrade_rollout_use_case_iot"></a>

IoT 企業は、複数の Amazon RDS データベースを使用して、毎日数百万のデバイスイベントを処理します。自動マイナーバージョンアップグレードによって本稼働サービスが中断されないようにする必要がありました。アップグレードロールアウトポリシーを使用すると、次のようになります。
+ 組織構造全体に適用されるポリシーを作成しました
+ アップグレードを最初に受信するように設定された Canary 環境
+ 早期アップグレード環境でのモニタリングの設定
+ 本番環境のアップグレード前に問題を検出して対応するための時間を確保
+ 複雑なカスタムアップグレードの自動化をシンプルなポリシーに置き換えました
+ データベースバージョンを最新の状態に保ちながら、本稼働ワークロードの高可用性を維持

## サポートされている AWS サービス
<a name="orgs_manage_policies_upgrade_services"></a>

アップグレードロールアウトポリシーは、自動マイナーバージョンアップグレードをサポートしながら、次の AWS サービスと統合されます。


**アップグレードロールアウトポリシーでサポートされているサービス**  

| サービス名 | 目的 | 
| --- | --- | 
| Amazon Aurora PostgreSQL 互換エディション | [ マイナーバージョンの自動アップグレード](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html#Aurora.Maintenance.AMVU) | 
| Amazon Aurora MySQL 互換エディション | [ マイナーバージョンの自動アップグレード](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_UpgradeDBInstance.Maintenance.html#Aurora.Maintenance.AMVU) | 
| Amazon Relational Database Service for PostgreSQL | [ マイナーバージョンの自動アップグレード](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.PostgreSQL.Minor.html) | 
| SQL Server の Amazon Relational Database Service | [マイナーバージョンの自動アップグレード](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.SQLServer.html) | 
| Oracle 用 Amazon Relational Database Service  | [ マイナーバージョンの自動アップグレード](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.Oracle.Minor.html#oracle-minor-version-upgrade-tuning-on) | 
| MariaDB 用 Amazon Relational Database Service  | [ マイナーバージョンの自動アップグレード](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.MariaDB.Minor.html) | 
| Amazon Relational Database Service for MySQL | [ マイナーバージョンの自動アップグレード](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.MySQL.Minor.html) | 
| Amazon Relational Database Service for Db2 | [マイナーバージョンの自動アップグレード](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Db2.Concepts.VersionMgmt.html) | 

## 前提条件
<a name="orgs_manage_policies_upgrade_rollout_prerequisites"></a>

以下は、 でアップグレードロールアウトポリシーを管理するために必要な前提条件とアクセス許可です AWS Organizations。
+ AWS Organizations 管理アカウントまたは委任管理者アクセス
+ サポートされているサービスのリソース (現在は Amazon Aurora および Amazon Relational Database Service データベースエンジン)
+ アップグレードロールアウトポリシーを管理するための適切な IAM アクセス許可

## 次の手順
<a name="orgs_manage_policies_upgrade_rollout_next_steps"></a>

アップグレードロールアウトポリシーの使用を開始するには:

1. ポリシーを作成して管理する方法については、[アップグレードロールアウトポリシーの開始方法](orgs_manage_policies_upgrade_getting_started.md)「」を参照してください。

1. アップグレードロールアウトポリシーの実装[アップグレードロールアウトポリシーを使用するためのベストプラクティス](orgs_manage_policies_upgrade_best_practices.md)について調べる

1. を理解する [ロールアウトポリシーの構文と例をアップグレードする](orgs_manage_policies_upgrade_syntax.md)

# アップグレードロールアウトポリシーの開始方法
<a name="orgs_manage_policies_upgrade_getting_started"></a>

以下の手順に従って、組織でアップグレードロールアウトポリシーを実装します。各ステップは、実装を正常に完了するための詳細情報にリンクします。

## [開始する前に]
<a name="orgs_manage_policies_upgrade_getting_started_prerequisites"></a>

以下があることを確認します。
+ への管理アクセス AWS Organizations
+ サポートされている AWS サービス (Aurora や Amazon Relational Database Service など) のリソース
+ 必要な IAM アクセス許可が設定されている

## 実装手順
<a name="orgs_manage_policies_upgrade_getting_started_steps"></a>

1. [組織のアップグレードロールアウトポリシーを有効にします。](enable-policy-type.md)

1. [アップグレードロールアウトポリシーの仕組みを理解します。](orgs_manage_policies_upgrade_rollout.md#orgs_manage_policies_upgrade_rollout_how_work)
   + 開発、テスト、本番環境を特定する
   + 最初にアップグレードするリソース、次にアップグレードするリソース、最後にアップグレードするリソースを決定する
   + リソース識別のためのタグ付け戦略を文書化する

1.  [アップグレードロールアウトポリシーを作成する](orgs_policies_create.md#create-upgrade-rollout-policy-procedure): 
   + デフォルトのロールアウト順序を定義する (組織単位またはアカウントレベル)
   + タグを使用してリソースターゲットを指定する
   + ポリシーの除外を設定する

1. [テストに使用できる単一のメンバーアカウントに、アップグレードロールアウトポリシーをアタッチします。](orgs_policies_attach.md)
   + テスト組織単位から開始する
   + ポリシーの継承を検証する
   + ポリシーのアタッチステータスを確認する

1. アップグレード注文戦略に従ってリソースにタグを付けます。
   + 最初のアップグレードのために開発リソースにタグを適用する
   + 2 次アップグレードのタグテストリソース
   + 最終注文アップグレード用に本番稼働用リソースを指定する

1. ポリシーを監視および検証します。
   + アップグレード順序の割り当てを確認する
   + テストリソースに対するポリシーの影響を検証する

1. アップグレードプロセスをテストします。
   + サービスアップグレードが利用可能になるまで待機する
   + 環境を通じてアップグレードの進行状況をモニタリングする
   + アップグレードが指定された順序に従っていることを確認する

1. 必要に応じて、追加の組織単位のアップグレードロールアウトポリシーを有効にする

**その他の情報**
+ [アップグレードロールアウトポリシー構文とポリシーの例について説明します。](orgs_manage_policies_upgrade_syntax.md)

# アップグレードロールアウトポリシーを使用するためのベストプラクティス
<a name="orgs_manage_policies_upgrade_best_practices"></a>

AWS では、アップグレードロールアウトポリシーを使用するための以下のベストプラクティスを推奨しています。

**Topics**
+ [小規模から始めて徐々にスケールする](#orgs_manage_policies_upgrade_best_practices_scale)
+ [レビュープロセスを確立する](#orgs_manage_policies_upgrade_best_practices_review)
+ [ポリシーの変更を効果的に検証する](#orgs_manage_policies_upgrade_best_practices_validate)
+ [変更のモニタリングと伝達](#orgs_manage_policies_upgrade_best_practices_monitor)
+ [コンプライアンスとセキュリティを維持する](#orgs_manage_policies_upgrade_best_practices_compliance)
+ [運用効率の最適化](#orgs_manage_policies_upgrade_best_practices_optimize)

## 小規模から始めて徐々にスケールする
<a name="orgs_manage_policies_upgrade_best_practices_scale"></a>

重要ではない環境の単一のアカウントにアタッチされたテストポリシーを使用して実装を開始します。このアプローチにより、重要なワークロードを中断するリスクなしに、アップグレードロールアウトポリシーの動作と影響を検証できます。ポリシーが正常に機能することを確認したら、組織構造を段階的に上に移動して、より多くのアカウントと組織単位を含めます。

この段階的なスケーリングは、実装プロセスの早い段階で問題を特定して対処するのに役立ちます。環境の多様性を表すリソースのパイロットグループを作成することを検討しますが、運用上のリスクは最小限です。各拡張フェーズの結果を文書化して、今後のポリシーのロールアウトと調整を通知します。

## レビュープロセスを確立する
<a name="orgs_manage_policies_upgrade_best_practices_review"></a>

新しいアップグレードロールアウトポリシー属性をモニタリングし、ポリシー例外を評価する定期的なレビュープロセスを実装します。これらのレビューは、組織のセキュリティおよび運用要件と一致する必要があります。ポリシーの有効性を確認するスケジュールを作成し、調整のドキュメントを維持します。

レビュープロセスには、どのリソースがポリシーによって管理されているかの定期的な評価、アップグレード注文が意図した戦略と一致しているかの検証、ポリシー例外の評価を含める必要があります。時間の経過とともにポリシーの進化を追跡するために、ポリシーが変更ログを更新および維持する必要がある時期の基準を確立することを検討してください。

## ポリシーの変更を効果的に検証する
<a name="orgs_manage_policies_upgrade_best_practices_validate"></a>

アップグレードロールアウトポリシーを変更したら、組織の各レベルで代表的なアカウントの有効なポリシーを確認します。 AWS マネジメントコンソールまたは `DescribeEffectivePolicy` API オペレーションを使用して、変更が意図した影響を与えることを確認します。この検証には、さまざまな組織単位のリソースをチェックし、継承が期待どおりに機能することの確認を含める必要があります。

明示的なアップグレード順序が割り当てられているリソースと、デフォルト値を使用しているリソースには特に注意してください。タグベースのターゲティングの検証、メンテナンスウィンドウの調整の確認、ポリシーの継承のテストを含む検証チェックリストを確立します。

## 変更のモニタリングと伝達
<a name="orgs_manage_policies_upgrade_best_practices_monitor"></a>

アップグレードロールアウトポリシーの包括的なモニタリングを確立し、アップグレード関連情報を共有するための明確な通信チャネルを作成します。アップグレードの失敗に対処するための明確な手順を文書化し、さまざまなシナリオに対応する計画を作成します。

アップグレードポリシーの影響を受けるリソースを管理するチームとの定期的なコミュニケーションを維持します。今後のアップグレードと環境全体の予想される進行状況を可視化するダッシュボードの作成を検討してください。

## コンプライアンスとセキュリティを維持する
<a name="orgs_manage_policies_upgrade_best_practices_compliance"></a>

アップグレードのロールアウトポリシーを定期的に監査して、コンプライアンス要件に準拠していることを確認します。すべてのポリシー決定を文書化し、アップグレードパターンと例外の明確な記録を維持します。ポリシー変更に関するセキュリティコントロールを実装し、 を使用してポリシー変更の監査証跡を維持します AWS CloudTrail。

ポリシー管理機能へのアクセス許可を定期的に確認し、ポリシー管理のための最小特権アクセスを実装します。緊急ポリシーの変更手順を作成し、セキュリティ関連のアップグレード要件のドキュメントを維持します。

## 運用効率の最適化
<a name="orgs_manage_policies_upgrade_best_practices_optimize"></a>

必要なコントロールを維持しながら、運用上のオーバーヘッドを最小限に抑えるようにポリシーを設計します。意図しない動作を防ぐため、さまざまなユースケースでタグを再利用しないでください。可能な場合はポリシーコンプライアンスチェックを自動化し、一般的なポリシー管理タスクの標準運用手順を作成します。

さまざまなタイプのアップグレードシナリオ用のテンプレートを作成し、正常なポリシーパターンのドキュメントを維持することを検討してください。運用メトリクスの定期的なレビューは、ポリシーの最適化とプロセスの改善の機会を特定するのに役立ちます。

# ロールアウトポリシーの構文と例をアップグレードする
<a name="orgs_manage_policies_upgrade_syntax"></a>

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

**Topics**
+ [考慮事項](#orgs_manage_policies_upgrade_syntax_considerations)
+ [基本的なポリシー構造](#orgs_manage_policies_upgrade_syntax_structure)
+ [ポリシーの構成要素](#orgs_manage_policies_upgrade_syntax_components)
+ [ロールアウトポリシーをアップグレードする例](#orgs_manage_policies_upgrade_syntax_examples)

## 考慮事項
<a name="orgs_manage_policies_upgrade_syntax_considerations"></a>

アップグレードロールアウトポリシーを実装するときは、次の重要な要素を考慮してください。
+ ポリシー名は組織内で一意でなければならず、明確かつわかりやすいものでなければなりません。ポリシーの目的と範囲を反映する名前を選択します。詳細については、「[運用効率の最適化](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_optimize)」を参照してください。
+ 広範なデプロイの前にテストが不可欠です。本番環境以外の環境で新しいポリシーを最初に検証し、徐々に拡張して目的の動作を確認します。詳細については、「[小規模から始めて徐々にスケールする](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_scale)」を参照してください。
+ ポリシーの変更が組織全体に反映されるまでに数時間かかる場合があります。それに応じて実装を計画し、適切なモニタリングが実施されていることを確認します。詳細については、「[変更のモニタリングと伝達](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_monitor)」を参照してください。
+ JSON 形式は有効で、ポリシーの最大サイズである 5,120 バイト以内である必要があります。要件を満たすと同時に、ポリシー構造をできるだけシンプルに保ちます。
+ 定期的なポリシーレビューは、有効性を維持するのに役立ちます。ポリシーの定期的な評価をスケジュールして、ポリシーが引き続き組織のニーズを満たしていることを確認します。詳細については、「[レビュープロセスを確立する](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_review)」を参照してください。
+ アップグレード順序が割り当てられていないリソースは、デフォルトで「2 番目の」順序になります。デフォルトに依存するのではなく、重要なリソースのアップグレード順序を明示的に設定することを検討してください。詳細については、「[ポリシーの変更を効果的に検証する](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_validate)」を参照してください。
+ 手動アップグレードは、ポリシー定義のアップグレード順序よりも優先されます。変更管理プロセスが自動アップグレードシナリオと手動アップグレードシナリオの両方を考慮に入れていることを確認します。詳細については、「[レビュープロセスを確立する](orgs_manage_policies_upgrade_best_practices.md#orgs_manage_policies_upgrade_best_practices_review)」を参照してください。

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

## 基本的なポリシー構造
<a name="orgs_manage_policies_upgrade_syntax_structure"></a>

アップグレードロールアウトポリシーは、以下の主要な要素を含む 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"
                  }
               }
            }
         }
      }
   }
}
```

## ポリシーの構成要素
<a name="orgs_manage_policies_upgrade_syntax_components"></a>

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

### デフォルトのパッチ順序の設定
<a name="orgs_manage_policies_upgrade_syntax_components_default"></a>

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

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

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

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

### タグによるリソースレベルの上書き
<a name="orgs_manage_policies_upgrade_syntax_components_tags"></a>

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

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

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

## ロールアウトポリシーをアップグレードする例
<a name="orgs_manage_policies_upgrade_syntax_examples"></a>

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

### 例 1: 開発環境を最初に
<a name="orgs_manage_policies_upgrade_syntax_example1"></a>

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

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

### 例 2: 本番環境の最終
<a name="orgs_manage_policies_upgrade_syntax_example2"></a>

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

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

### 例 3: タグを使用した複数のアップグレード順序
<a name="orgs_manage_policies_upgrade_syntax_example3"></a>

次の例は、異なる値を持つ単一のタグキーを使用して 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"
                  }
               }
            }
         }
      }
   }
}
```