翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # での設定プロファイルの作成 AWS AppConfig *設定データ*は、アプリケーションの動作に影響する設定のコレクションです。*設定プロファイル*には、 が保存場所に設定データを配置 AWS AppConfig できるようにする URI と設定タイプが含まれます。 は次のタイプの設定プロファイル AWS AppConfig をサポートします。 + **機能フラグ**: 機能フラグを使用して、アプリケーション内の機能を有効または無効にしたり、フラグ属性を使用してアプリケーション機能のさまざまな特性を設定したりできます。 は、 AWS AppConfig ホストされた設定ストアに、フラグとフラグ属性に関するデータとメタデータを含む機能フラグ形式で機能フラグ設定 AWS AppConfig を保存します。機能フラグ設定の URI は、シンプルに `hosted` です。 + **フリーフォーム設定**: フリーフォーム設定では、次のいずれかの AWS のサービス および Systems Manager ツールにデータを保存できます。 + AWS AppConfig ホスト設定ストア + Amazon Simple Storage Service + AWS CodePipeline + AWS Secrets Manager + AWS Systems Manager (SSM) パラメータストア + SSM ドキュメントストア **注記** 可能な限り、ホストされた設定ストアで設定データをホストすることをお勧めします。ホスト AWS AppConfig された設定ストアは、ほとんどの機能と機能強化を提供します。 さまざまなタイプの設定データと、機能フラグで使用する方法、または設定プロファイルを使用しない方法を理解するのに役立つ設定データサンプルをいくつか紹介します。 **機能フラグ設定データ** 次の機能フラグ設定データは、モバイル決済とデフォルト決済を地域ごとに有効または無効にします。 ------ #### [ JSON ] ``` { "allow_mobile_payments": { "enabled": false }, "default_payments_per_region": { "enabled": true } } ``` ------ #### [ YAML ] ``` --- allow_mobile_payments: enabled: false default_payments_per_region: enabled: true ``` ------ **オペレーション設定データ** 次のフリーフォームの設定データでは、アプリケーションのリクエスト処理方法に制限が課されます。 ------ #### [ JSON ] ``` { "throttle-limits": { "enabled": "true", "throttles": [ { "simultaneous_connections": 12 }, { "tps_maximum": 5000 } ], "limit-background-tasks": [ true ] } } ``` ------ #### [ YAML ] ``` --- throttle-limits: enabled: 'true' throttles: - simultaneous_connections: 12 - tps_maximum: 5000 limit-background-tasks: - true ``` ------ **アクセス制御リスト設定データ** 以下のアクセス制御リストのフリーフォーム設定データでは、アプリケーションにアクセスできるユーザーまたはグループを指定します。 ------ #### [ JSON ] ``` { "allow-list": { "enabled": "true", "cohorts": [ { "internal_employees": true }, { "beta_group": false }, { "recent_new_customers": false }, { "user_name": "Jane_Doe" }, { "user_name": "John_Doe" } ] } } ``` ------ #### [ YAML ] ``` --- allow-list: enabled: 'true' cohorts: - internal_employees: true - beta_group: false - recent_new_customers: false - user_name: Jane_Doe - user_name: Ashok_Kumar ``` ------ **Topics** + [で機能フラグ設定プロファイルを作成する AWS AppConfig](appconfig-creating-configuration-and-profile-feature-flags.md) + [での無料フォーム設定プロファイルの作成 AWS AppConfig](appconfig-free-form-configurations-creating.md) + [非ネイティブデータソースの設定プロファイルの作成](appconfig-creating-configuration-profile-other-data-sources.md) # で機能フラグ設定プロファイルを作成する AWS AppConfig 機能フラグを使用して、アプリケーション内の機能を有効または無効にしたり、フラグ属性を使用してアプリケーション機能のさまざまな特性を設定したりできます。 は、機能フラグ設定を、フラグとフラグ属性に関するデータとメタデータを含む機能フラグ形式で AWS AppConfig ホストされた設定ストアに AWS AppConfig 保存します。 **注記** 機能フラグ設定プロファイルを作成するときは、設定プロファイルワークフローの一部として基本的な機能フラグを作成できます。 は、マルチバリアント機能フラグ AWS AppConfig もサポートしています。*マルチバリアント機能フラグ*を使用すると、リクエストに対して返す可能性のあるフラグ値のセットを定義できます。バリアントで設定されたフラグをリクエストする場合、アプリケーションは一連のユーザー定義ルールに対して AWS AppConfig を評価するコンテキストを提供します。リクエストで指定されたコンテキストとバリアントに定義されたルールに応じて、 は異なるフラグ値をアプリケーションに AWS AppConfig 返します。 マルチバリアント機能フラグを作成するには、まず設定プロファイルを作成し、次に設定プロファイル内のフラグを編集してバリアントを追加します。詳細については、「[マルチバリアント機能フラグの作成](appconfig-creating-multi-variant-feature-flags.md)」を参照してください。 **Topics** + [機能フラグ属性について](#appconfig-creating-configuration-profile-feature-flag-attributes) + [機能フラグ設定プロファイルの作成 (コンソール)](appconfig-creating-feature-flag-configuration-create-console.md) + [機能フラグ設定プロファイルの作成 (コマンドライン)](appconfig-creating-feature-flag-configuration-commandline.md) + [マルチバリアント機能フラグの作成](appconfig-creating-multi-variant-feature-flags.md) + [AWS.AppConfig.FeatureFlags のタイプリファレンスを理解する](appconfig-type-reference-feature-flags.md) + [機能フラグの以前のバージョンを新しいバージョンに保存する](appconfig-creating-configuration-profile-feature-flags-editing-version.md) ## 機能フラグ属性について 機能フラグ設定プロファイルを作成する場合、または既存の設定プロファイル内に新しいフラグを作成する場合、フラグの属性と対応する制約を指定できます。属性は、機能フラグに関連するプロパティを表すために、機能フラグに関連付けるフィールドです。属性は、フラグキーとフラグの `enable` または `disable` の値を使用してアプリケーションに配信されます。 制約により、予期しない属性値がアプリケーションにデプロイされないようにします。次のイメージは例を示しています。 ![\[AWS AppConfig 機能フラグのフラグ属性の例\]](http://docs.aws.amazon.com/ja_jp/appconfig/latest/userguide/images/appconfig-flag-attributes.png) **注記** フラグ属性に関する以下の情報に注意してください。 属性名には、「有効」という単語を残します。「有効」という名前の機能フラグ属性は作成できません。他の予約語はありません。　 機能フラグの属性は、このフラグが有効になっている場合にのみ `GetLatestConfiguration` レスポンスに含まれます。 特定のフラグのフラグ属性キーは一意である必要があります。 AWS AppConfig は、次のタイプのフラグ属性とそれに対応する制約をサポートします。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/appconfig/latest/userguide/appconfig-creating-configuration-and-profile-feature-flags.html) # 機能フラグ設定プロファイルの作成 (コンソール) AWS AppConfig コンソールを使用して AWS AppConfig 機能フラグ設定プロファイルを作成するには、次の手順に従います。設定プロファイルを作成するときに、基本的な機能フラグも作成できます。 **設定プロファイルを作成する方法** 1. [https://console.aws.amazon.com/systems-manager/appconfig/](https://console.aws.amazon.com/systems-manager/appconfig/) で AWS Systems Manager コンソールを開きます。 1. ナビゲーションペインで、**[アプリケーション]** を選択し、[でのアプリケーションの名前空間の作成 AWS AppConfig](appconfig-creating-namespace.md) で作成したアプリケーションを選択します。 1. **[設定プロファイルと機能フラグ]** タブで、**[設定を作成]** を選択します。 1. **[設定オプション]** セクションで、**[機能フラグ]** を選択します。 1. **[設定プロファイル]** セクションで、**[設定プロファイル名]** に名前を入力します。 1. (オプション) **[説明]** を展開し、説明を入力します。 1. (オプション) **[追加オプション]** を展開し、必要に応じて以下を完了します。 1. **暗号化**リストで、リストから AWS Key Management Service (AWS KMS) キーを選択します。このカスタマーマネージドキーを使用すると、 AWS AppConfig ホストされた設定ストアで新しい設定データバージョンを暗号化できます。このキーの詳細については、「[のセキュリティ AWS AppConfig](appconfig-security.md)」の「**AWS AppConfig はカスタマーマネージャーキーをサポートします**」を参照してください。 1. **[タグ]** セクションで、**[新しいタグを追加]** を選択し、キーとオプションの値を指定します。 1. [**次へ**] を選択します。 1. **[機能フラグ定義]** セクションの **[フラグ名]** に名前を入力します。 1. **[フラグキー]** には、フラグ識別子を入力して、同じ設定プロファイル内のフラグを区別します。同じ設定プロファイル内のフラグに同じキーを設定することはできません。フラグを作成した後、フラグ名は編集できますが、フラグキーは編集できません。 1. (オプション) **[説明]** を展開し、このフラグに関する情報を入力します。 1. Select **これは短期フラグ**であり、オプションで、フラグを無効化または削除する必要がある日付を選択します。 AWS AppConfig は廃止日のフラグを無効に*しません*。 1. (オプション) **[機能フラグ属性]** セクションで、**[属性を定義]** を選択します。属性を使用すると、フラグ内に追加の値を指定できます。属性と制約の詳細については、「[機能フラグ属性について](appconfig-creating-configuration-and-profile-feature-flags.md#appconfig-creating-configuration-profile-feature-flag-attributes)」を参照してください。 1. **[キー]** には、フラグキーを指定し、**[タイプ]** リストからそのタイプを選択します。**[値]** および **[制約]** フィールドでサポートされているオプションについては、属性に関する前述のセクションを参照してください。 1. **必須の値** を選択して、属性値が必須かどうかを指定します。 1. 属性を追加するには、**[属性を定義]** を選択します。 1. **[機能フラグ値]** セクションで、**[有効]** を選択してフラグを有効にします。該当する場合、同じトグルを使用して、指定された廃止日に達したときにフラグを無効にします。 1. [**次へ**] を選択します。 1. **[確認して保存]** ページで、フラグの詳細を確認してから **[保存してデプロイを続ける]** を選択します。 [に機能フラグと設定データをデプロイする AWS AppConfig](deploying-feature-flags.md) に進みます。 # 機能フラグ設定プロファイルの作成 (コマンドライン) 次の手順では、 AWS Command Line Interface (Linux または Windows) または Tools for Windows PowerShell を使用して AWS AppConfig 機能フラグ設定プロファイルを作成する方法について説明します。設定プロファイルを作成するときに、基本的な機能フラグも作成できます。 **機能フラグの設定を作成する** 1. を開きます AWS CLI。 1. **タイプ** に `AWS.AppConfig.FeatureFlags` を指定して、機能フラグの設定プロファイルを作成します。設定プロファイルでは、ロケーション URI に `hosted` を使用する必要があります。 ------ #### [ Linux ] ``` aws appconfig create-configuration-profile \ --application-id APPLICATION_ID \ --name CONFIGURATION_PROFILE_NAME \ --location-uri hosted \ --type AWS.AppConfig.FeatureFlags ``` ------ #### [ Windows ] ``` aws appconfig create-configuration-profile ^ --application-id APPLICATION_ID ^ --name CONFIGURATION_PROFILE_NAME ^ --location-uri hosted ^ --type AWS.AppConfig.FeatureFlags ``` ------ #### [ PowerShell ] ``` New-APPCConfigurationProfile ` -Name CONFIGURATION_PROFILE_NAME ` -ApplicationId APPLICATION_ID ` -LocationUri hosted ` -Type AWS.AppConfig.FeatureFlags ``` ------ 1. 機能フラグの設定データを作成します。データは JSON 形式であり、`AWS.AppConfig.FeatureFlags` JSON スキーマに準拠していることが必要です。スキーマの詳細については、「[AWS.AppConfig.FeatureFlags のタイプリファレンスを理解する](appconfig-type-reference-feature-flags.md)」を参照してください。 1. `CreateHostedConfigurationVersion` API を使用して、機能フラグの設定データを AWS AppConfigに保存します。 ------ #### [ Linux ] ``` aws appconfig create-hosted-configuration-version \ --application-id APPLICATION_ID \ --configuration-profile-id CONFIGURATION_PROFILE_ID \ --content-type "application/json" \ --content file://path/to/feature_flag_configuration_data.json \ --cli-binary-format raw-in-base64-out ``` ------ #### [ Windows ] ``` aws appconfig create-hosted-configuration-version ^ --application-id APPLICATION_ID ^ --configuration-profile-id CONFIGURATION_PROFILE_ID ^ --content-type "application/json" ^ --content file://path/to/feature_flag_configuration_data.json ^ --cli-binary-format raw-in-base64-out ``` ------ #### [ PowerShell ] ``` New-APPCHostedConfigurationVersion ` -ApplicationId APPLICATION_ID ` -ConfigurationProfileId CONFIGURATION_PROFILE_ID ` -ContentType "application/json" ` -Content file://path/to/feature_flag_configuration_data.json ``` ------ コマンドは、`Content` パラメータに指定されたコンテンツをディスクからロードします。コンテンツは次の例のようになります。 ``` { "flags": { "ui_refresh": { "name": "UI Refresh" } }, "values": { "ui_refresh": { "enabled": false, "attributeValues": { "dark_mode_support": true } } }, "version": "1" } ``` システムが以下のような情報をレスポンスします。 ------ #### [ Linux ] ``` { "ApplicationId" : "ui_refresh", "ConfigurationProfileId" : "UI Refresh", "VersionNumber" : "1", "ContentType" : "application/json" } ``` ------ #### [ Windows ] ``` { "ApplicationId" : "ui_refresh", "ConfigurationProfileId" : "UI Refresh", "VersionNumber" : "1", "ContentType" : "application/json" } ``` ------ #### [ PowerShell ] ``` ApplicationId : ui_refresh ConfigurationProfileId : UI Refresh VersionNumber : 1 ContentType : application/json ``` ------ `service_returned_content_file` には、 AWS AppConfig 生成されたメタデータを含む設定データが含まれています。 **注記** ホストされた設定バージョンを作成すると、 AWS AppConfig はデータが JSON `AWS.AppConfig.FeatureFlags` スキーマに準拠していることを確認します。 AWS AppConfig さらに、 は、データ内の各機能フラグ属性が、それらの属性に定義した制約を満たしていることを確認します。 # マルチバリアント機能フラグの作成 機能フラグバリアントを使用すると、リクエストに対して返す可能性のあるフラグ値のセットを定義できます。マルチバリアントフラグには、異なるステータス (有効または無効) を設定することもできます。バリアントで設定されたフラグをリクエストする場合、アプリケーションは一連のユーザー定義ルールに対して AWS AppConfig を評価するコンテキストを提供します。リクエストで指定されたコンテキストとバリアントに定義されたルールに応じて、 は異なるフラグ値をアプリケーションに AWS AppConfig 返します。 次のスクリーンショットは、3 つのユーザー定義バリアントとデフォルトのバリアントを持つ機能フラグの例を示しています。 ![\[バリアントを含む機能フラグのスクリーンショットの例。\]](http://docs.aws.amazon.com/ja_jp/appconfig/latest/userguide/images/flag-variant-example.png) **Topics** + [マルチバリアント機能フラグの概念と一般的なユースケースを理解する](appconfig-creating-multi-variant-feature-flags-concepts.md) + [マルチバリアント機能フラグルールについて](appconfig-creating-multi-variant-feature-flags-rules.md) + [マルチバリアント機能フラグの作成](appconfig-creating-multi-variant-feature-flags-procedures.md) # マルチバリアント機能フラグの概念と一般的なユースケースを理解する 機能フラグバリアントをよりよく理解するために、このセクションでは、フラグバリアントの概念と一般的なユースケースについて説明します。 **概念** + **機能フラグ**: アプリケーションの機能の動作を制御するために使用される AWS AppConfig 設定タイプ。フラグには、ステータス (有効または無効) と、任意の文字列、数値、ブール値、または配列値を含むオプションの属性セットがあります。 + **機能フラグバリアント**: 機能フラグに属するステータス値と属性値の特定の組み合わせ。機能フラグには複数のバリアントがある場合があります。 + **バリアントルール**: 機能フラグバリアントを選択するために使用されるユーザー定義の式。各バリアントには、 が AWS AppConfig 評価して返すかどうかを決定する独自のルールがあります。 + **デフォルトバリアント**: 他のバリアントが選択されていない場合に返される特別なバリアント。すべてのマルチバリアント機能フラグにはデフォルトのバリアントがあります。 デフォルトのバリアントは、バリアントの順序で最後に設定する必要があり、ルールを関連付けることはできません。最後に定義されていない場合、マルチバリアントフラグを作成しようとする`BadRequestException`と、 は AWS AppConfig を返します。 + **コンテキスト**: 設定の取得時に AWS AppConfig に渡されるユーザー定義のキーと値。コンテキスト値は、ルール評価中に、返す機能フラグバリアントを選択するために使用されます。 **注記** AWS AppConfig エージェントはバリアントルールを評価し、指定されたコンテキストに基づいてリクエストに適用されるルールを決定します。マルチバリアント機能フラグの取得の詳細については、「[基本およびマルチバリアント機能フラグの取得](appconfig-integration-retrieving-feature-flags.md)」を参照してください。 **一般的なユースケース** このセクションでは、機能フラグバリアントの 2 つの一般的なユースケースについて説明します。 *ユーザーセグメンテーション* ユーザーセグメンテーションは、特定の属性に基づいてユーザーを分割するプロセスです。例えば、フラグバリアントを使用して、ユーザー ID、地理的位置、デバイスタイプ、または購入頻度に基づいて、一部のユーザーには機能を公開し、他のユーザーには公開しないようにすることができます。 購入頻度の例を使用して、コマースアプリケーションが顧客ロイヤルティを向上させる機能をサポートしているとします。フラグバリアントを使用すると、ユーザーが最後に何かを購入した日時に基づいて、ユーザーに表示されるさまざまなインセンティブタイプを設定できます。新規ユーザーには顧客になることを促すために小さな割引を提供し、リピーターの顧客には新しいカテゴリから何かを購入するとより大きな割引を提供することができます。 *トラフィック分割* トラフィック分割とは、定義したコンテキスト値に基づいて、ランダムでありながら一貫性のあるフラグバリアントを選択するプロセスです。例えば、少数のユーザー (ユーザー ID で識別) に特定のバリアントを表示する実験を実行することができます。または、ロールアウト全体で一貫したユーザーエクスペリエンスを維持しながら、機能が最初にユーザーの 5%、次に 15%、次に 40%、次に 100% に公開される段階的な機能ロールアウトを実行することもできます。 実験例を使用すると、フラグバリアントを使用して、アプリケーションのホームページで主なアクションの新しいボタンスタイルをテストし、クリック数が増えるかどうかを確認できます。実験では、トラフィック分割ルールを使用してフラグバリアントを作成し、5% のユーザーを選択して新しいスタイルを表示できます。デフォルトのバリアントは、既存のスタイルを表示し続ける必要があるユーザーを示します。実験が成功した場合、パーセンテージ値を増やすことも、そのバリアントをデフォルトにすることもできます。 # マルチバリアント機能フラグルールについて 機能フラグバリアントを作成するときは、そのバリアントのルールを指定します。ルールは、コンテキスト値を入力として受け取り、ブール値を出力として生成する式です。例えば、アカウント ID で識別されるベータユーザーのフラグバリアントを選択するルールを定義して、ユーザーインターフェイスの更新をテストできます。このシナリオでは、次の操作を行います。 1. *UI Refresh* という新しい機能フラグ設定プロファイルを作成します。 1. *ui\$1refresh* という新しい機能フラグを作成します。 1. バリアントを追加するには、作成後に機能フラグを編集します。 1. *BetaUsers* という新しいバリアントを作成して有効にします。 1. リクエストコンテキストのアカウント ID が、新しいベータエクスペリエンスの表示が承認されたアカウント ID のリストにある場合にバリアントを選択する *BetaUsers* のルールを定義します。 1. デフォルトのバリアントのステータスが **[無効]** に設定されていることを確認します。 **注記** バリアントは、コンソールで定義されている順序に基づいて順序付きリストとして評価されます。リストの先頭にあるバリアントが最初に評価されます。指定されたコンテキストに一致するルールがない場合、 はデフォルトのバリアント AWS AppConfig を返します。 が機能フラグリクエスト AWS AppConfig を処理すると、AccountID (この例の場合) を含む指定されたコンテキストが最初に BetaUsers バリアントと比較されます。コンテキストが BetaUsers のルールと一致する場合、 はベータエクスペリエンスの設定データを AWS AppConfig 返します。コンテキストにアカウント ID が含まれていない場合、またはアカウント ID が 123 以外にある場合、 はデフォルトルールの設定データを AWS AppConfig 返します。つまり、ユーザーは本番環境で現在のエクスペリエンスを表示します。 **注記** マルチバリアント機能フラグの取得については、「[基本およびマルチバリアント機能フラグの取得](appconfig-integration-retrieving-feature-flags.md)」を参照してください。 # マルチバリアント機能フラグのルールの定義 バリアントルールは、1 つ以上のオペランドと演算子で構成される式です。オペランドは、ルールの評価中に使用される特定の値です。オペランド値は、リテラル数値や文字列などの静的値、またはコンテキストで見つかった値や別の式の結果などの変数のいずれかにすることができます。「より大きい」などの演算子は、値を生成するオペランドに適用されるテストまたはアクションです。バリアントルール式を有効にするには、「true」または「false」のいずれかを生成する必要があります。 **オペランド** **** | 型 | 説明 | 例 | | --- | --- | --- | | String | UTF-8 文字のシーケンス。二重引用符で囲まれています。 | 
"apple", "Ḽơᶉëᶆ ȋṕšᶙṁ"
| | 整数 | 64 ビットの整数値。 | 
-7, 42
| | 浮動小数点数 | 64 ビットの IEEE-754 浮動小数点値。 | 
3.14, 1.234e-5
| | タイムスタンプ | [日付と時刻の形式に関する W3C ノート](https://www.w3.org/TR/NOTE-datetime)で説明されている特定の時刻。 | 
2012-03-04T05:06:07-08:00, 2024-01
| | ブール値 | true または false 値。 | 
true, false
| | コンテキスト値 | ルール評価中にコンテキストから取得される \$1*key* 形式のパラメータ化された値。 | 
$country, $userId
| **比較演算子** **** | 演算子 | 説明 | 例 | | --- | --- | --- | | eq | コンテキスト値が指定された値と等しいかどうかを判断します。 | 
(eq $state "Virginia")
| | gt | コンテキスト値が指定された値より大きいかどうかを判断します。 | 
(gt $age 65)
| | gte | コンテキスト値が指定された値以上かどうかを判断します。 | 
(gte $age 65)
| | lt | コンテキスト値が指定された値よりも小さいかどうかを判断します。 | 
(lt $age 65)
| | lte | コンテキスト値が指定された値以下かどうかを判断します。 | 
(lte $age 65)
| **論理演算子** **** | 演算子 | 説明 | 例 | | --- | --- | --- | | と | 両方のオペランドが true かどうかを判断します。 | 
(and 
    (eq $state "Virginia") 
    (gt $age 65)
)
| | または | 少なくとも 1 つのオペランドが true かどうかを判断します。 | 
(or
    (eq $state "Virginia") 
    (gt $age 65)
)
| | not | 式の値を反転します。 | 
(not (eq $state "Virginia"))
| **カスタム演算子** **** | 演算子 | 説明 | 例 | | --- | --- | --- | | begins\$1with | コンテキスト値が特定のプレフィックスで始まるかどうかを判断します。 | 
(begins_with $state "A")
| | ends\$1with | コンテキスト値が特定のプレフィックスで終わるかどうかを判断します。 | 
(ends_with $email "amazon.com")
| | contains | コンテキスト値に特定の部分文字列が含まれているかどうかを判断します。 | 
(contains $promoCode "WIN")
| | 情報 | コンテキスト値が定数のリストに含まれるかどうかを判断します。 | 
(in $userId ["123", "456"])
| | matches | コンテキスト値が特定の正規表現パターンと一致するかどうかを判断します。 | 
(matches in::$greeting pattern::"h.*y")
| | exists | コンテキストキーに値が提供されたかどうかを判断します。 | 
(exists key::"country")
| | split | 指定されたコンテキスト値の一貫したハッシュ (複数可) に基づいて、トラフィックの特定の割合について `true` と評価します。`split` の仕組みの詳細については、このトピックの次のセクション「[split 演算子について](appconfig-creating-multi-variant-feature-flags-rules.md#appconfig-creating-multi-variant-feature-flags-rules-operators-split)」を参照してください。 `seed` はオプションのプロパティであることに注意してください。`seed` を指定しない場合、ハッシュは*ローカル*で一貫しており、そのフラグに対してトラフィックは一貫して分割されますが、同じコンテキスト値を受け取る他のフラグはトラフィックを異なる方法で分割する可能性があります。`seed` が指定されている場合、各一意の値によって、機能フラグ、設定プロファイル、および AWS アカウント間でトラフィックが一貫して分割されることが保証されます。 | 
(split pct::10 by::$userId seed::"abc")
| ## split 演算子について 次のセクションでは、さまざまなシナリオで使用した場合の `split` 演算子の動作について説明します。`split` は、指定されたコンテキスト値の一貫したハッシュに基づいて、トラフィックの特定の割合に対して `true` と評価します。これをよりよく理解するには、2 つのバリアントで分割を使用する次のベースラインシナリオを検討してください。 ``` A: (split by::$uniqueId pct::20) C: ``` 予想どおり、ランダムな一連の `uniqueId` 値を指定すると、次のようなディストリビューションが生成されます。 ``` A: 20% C: 80% ``` 3 つ目のバリアントを追加しつつ、次のように同じ分割割合を使用する場合: ``` A: (split by::$uniqueId pct::20) B: (split by::$uniqueId pct::20) C: ``` 最終的に、次のディストリビューションになります。 ``` A: 20% B: 0% C: 80% ``` この予期しないディストリビューションが発生する可能性があるのは、各バリアントルールが順番に評価され、最初の一致によって返されるバリアントが決定されるためです。ルール A が評価されると、`uniqueId` 値の 20% がそれと一致するため、最初のバリアントが返されます。次に、ルール B が評価されます。ただし、2 番目の分割ステートメントに一致するすべての `uniqueId` 値はバリアントルール A によって既に一致しているため、B に一致する値はありません。代わりにデフォルトのバリアントが返されます。 次に、3 番目の例を考えてみましょう。 ``` A: (split by::$uniqueId pct::20) B: (split by::$uniqueId pct::25) C: ``` 前の例と同様に、`uniqueId` 値の最初の 20% はルール A と一致します。バリアントルール B の場合、すべての `uniqueId` 値の 25% は一致しますが、その大半は既にルール A と一致しています。これにより、全体の 5% がバリアント B で、残りはバリアント C を受け取ります。ディストリビューションは次のようになります。 ``` A: 20% B: 5% C: 75% ``` **`seed` プロパティの使用** `seed` プロパティを使用すると、split 演算子が使用されている場所に関係なく、特定のコンテキスト値に対してトラフィックが一貫して分割されるようにできます。`seed` を指定しない場合、ハッシュは*ローカル*で一貫しており、そのフラグに対してトラフィックは一貫して分割されますが、同じコンテキスト値を受け取る他のフラグはトラフィックを異なる方法で分割する可能性があります。`seed` が指定されている場合、各一意の値によって、機能フラグ、設定プロファイル、および AWS アカウント間でトラフィックが一貫して分割されることが保証されます。 通常、お客様は、同じコンテキストプロパティでトラフィックを分割する場合、フラグ内のバリアント間で同じ `seed` 値を使用します。ただし、別の seed 値を使用することが適切な場合もあります。ルール A と B に異なる seed を使用する例を次に示します。 ``` A: (split by::$uniqueId pct::20 seed::"seed_one") B: (split by::$uniqueId pct::25 seed::"seed_two") C: ``` 以前と同様に、一致する `uniqueId` 値の 20% がルール A に一致します。つまり、値の 80% がフォールスルーされ、バリアントルール B に対してテストされます。seed が異なるため、A に一致する値と B に一致する値の間に相関はありません。ただし、分割対象となる `uniqueId` 値の数は全体の 80% に限られ、そのうちの 25% がルール B に一致し、75% は一致しません。これは次のディストリビューションに当てはまります。 ``` A: 20% B: 20% (25% of what falls through from A, or 25% of 80%) C: 60% ``` # マルチバリアント機能フラグの作成 このセクションの手順を使用して、機能フラグのバリアントを作成します。 **[開始する前に]** 次の重要な情報に注意してください。 + 既存の機能フラグを編集してバリアントを作成できます。*新しい設定プロファイルを作成するときに*、新しい機能フラグのバリアントを作成することはできません。まず、新しい設定プロファイルを作成するワークフローを完了する必要があります。設定プロファイルを作成したら、設定プロファイル内の任意のフラグにバリアントを追加できます。新しい設定プロファイルを作成する方法については、「[で機能フラグ設定プロファイルを作成する AWS AppConfig](appconfig-creating-configuration-and-profile-feature-flags.md)」を参照してください。 + Amazon EC2、Amazon ECS、Amazon EKS コンピューティングプラットフォームの機能フラグバリアントデータを取得するには、 AWS AppConfig エージェントバージョン 2.0.4416 以降を使用する必要があります。 + パフォーマンス上の理由から、 AWS CLI SDK は を呼び出してバリアントデータを取得 AWS AppConfig しません。 AWS AppConfig エージェントの詳細については、「」を参照してください[AWS AppConfig エージェントを使用して設定データを取得する方法](appconfig-agent-how-to-use.md)。 + 機能フラグバリアントを作成するときは、そのバリアントのルールを指定します。ルールは、リクエストコンテキストを入力として受け取り、ブール結果を出力として生成する式です。バリアントを作成する前に、フラグバリアントルールでサポートされているオペランドと演算子を確認してください。バリアントを作成する前にルールを作成できます。詳細については、「[マルチバリアント機能フラグルールについて](appconfig-creating-multi-variant-feature-flags-rules.md)」を参照してください。 **Topics** + [マルチバリアント機能フラグの作成 (コンソール)](#appconfig-creating-multi-variant-feature-flags-procedures-console) + [マルチバリアント機能フラグの作成 (コマンドライン)](#appconfig-creating-multi-variant-feature-flags-procedures-commandline) ## マルチバリアント機能フラグの作成 (コンソール) 次の手順では、 AWS AppConfig コンソールを使用して既存の設定プロファイルのマルチバリアント機能フラグを作成する方法について説明します。既存の機能フラグを編集してバリアントを作成することもできます。 **マルチバリアント機能フラグを作成するには** 1. [https://console.aws.amazon.com/systems-manager/appconfig/](https://console.aws.amazon.com/systems-manager/appconfig/) で AWS Systems Manager コンソールを開きます。 1. ナビゲーションペインで、**[アプリケーション]** を選択し、アプリケーションを選択します。 1. **[設定プロファイルと機能フラグ]** タブで、既存の機能フラグ設定プロファイルを選択します。 1. **[フラグ]** セクションで、**[新しいフラグの追加]** を選択します。 1. **[機能フラグ定義]** セクションの **[フラグ名]** に名前を入力します。 1. **[フラグキー]** には、フラグ識別子を入力して、同じ設定プロファイル内のフラグを区別します。同じ設定プロファイル内のフラグに同じキーを設定することはできません。フラグを作成した後、フラグ名は編集できますが、フラグキーは編集できません。 1. (オプション) **[説明]** フィールドに、このフラグに関する情報を入力します。 1. **[バリアント]** セクションで、**[マルチバリアントフラグ]** を選択します。 1. (オプション) **[機能フラグ属性]** セクションで、**[属性を定義]** を選択します。属性を使用すると、フラグ内に追加の値を指定できます。属性と制約の詳細については、「[機能フラグ属性について](appconfig-creating-configuration-and-profile-feature-flags.md#appconfig-creating-configuration-profile-feature-flag-attributes)」を参照してください。 1. **[キー]** には、フラグキーを指定し、**[タイプ]** リストからそのタイプを選択します。**[値]** および **[制約]** フィールドでサポートされているオプションについては、属性に関する前述のセクションを参照してください。 1. **必須の値** を選択して、属性値が必須かどうかを指定します。 1. 属性を追加するには、**[属性を定義]** を選択します。 1. 属性の変更を保存するには、**[適用]** を選択します。 1. **[機能フラグバリアント]** セクションで、**[バリアントを作成]** を選択します。 1. **[バリアント名]** に名前を入力します。 1. **[有効化された値]** トグルを使用してバリアントを有効にします。 1. **[ルール]** テキストボックスにルールを入力します。 1. **[バリアントを作成]** > **[上にバリアントを作成]** または **[下にバリアントを作成]** オプションを使用して、このフラグに追加のバリアントを作成します。 1. **[デフォルトバリアント]** セクションで、**[有効化された値]** トグルを使用してデフォルトバリアントを有効にします。必要に応じて、ステップ 10 で定義された属性の値を指定します。 1. **[Apply]** (適用) を選択します。 1. フラグとそのバリアントの詳細を確認し、**[フラグを作成]** を選択します。 新規の機能フラグとバリアントをデプロイする方法の詳細については、「[に機能フラグと設定データをデプロイする AWS AppConfig](deploying-feature-flags.md)」を参照してください。 ## マルチバリアント機能フラグの作成 (コマンドライン) 次の手順では、 AWS Command Line Interface (Linux または Windows) または Tools for Windows PowerShell を使用して、既存の設定プロファイルのマルチバリアント機能フラグを作成する方法について説明します。既存の機能フラグを編集してバリアントを作成することもできます。 **[開始する前に]** AWS CLIを使用して多変量機能フラグを作成する前に、以下のタスクを完了してください。 + 機能フラグ設定プロファイルを作成します。詳細については、「[で機能フラグ設定プロファイルを作成する AWS AppConfig](appconfig-creating-configuration-and-profile-feature-flags.md)」を参照してください。 + AWS CLIを最新バージョンに更新します。詳細については、「*AWS Command Line Interface ユーザーガイド*」の「[AWS CLIの最新バージョンをインストールまたは更新する](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html)」を参照してください。 **マルチバリアント機能フラグを作成するには** 1. 作成するマルチバリアントフラグの詳細を指定する設定ファイルをローカルマシンに作成します。ファイル拡張子 (`.json`) を付けてこのファイルを保存します。ファイルは [https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-type-reference-feature-flags.html](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-type-reference-feature-flags.html) JSON スキーマに準拠している必要があります。設定ファイルのスキーマの内容は、次のようになります。 ``` { "flags": { "FLAG_NAME": { "attributes": { "ATTRIBUTE_NAME": { "constraints": { "type": "CONSTRAINT_TYPE" } } }, "description": "FLAG_DESCRIPTION", "name": "VARIANT_NAME" } }, "values": { "VARIANT_VALUE_NAME": { "_variants": [ { "attributeValues": { "ATTRIBUTE_NAME": BOOLEAN }, "enabled": BOOLEAN, "name": "VARIANT_NAME", "rule": "VARIANT_RULE" }, { "attributeValues": { "ATTRIBUTE_NAME": BOOLEAN }, "enabled": BOOLEAN, "name": "VARIANT_NAME", "rule": "VARIANT_RULE" }, { "attributeValues": { "ATTRIBUTE_NAME": BOOLEAN }, "enabled": BOOLEAN, "name": "VARIANT_NAME", "rule": "VARIANT_RULE" }, { "attributeValues": { "ATTRIBUTE_NAME": BOOLEAN }, "enabled": BOOLEAN, "name": "VARIANT_NAME", "rule": "VARIANT_RULE" } ] } }, "version": "VERSION_NUMBER" } ``` 以下は、3 つのバリアントとデフォルトのバリアントの例です。 ``` { "flags": { "ui_refresh": { "attributes": { "dark_mode_support": { "constraints": { "type": "boolean" } } }, "description": "A release flag used to release a new UI", "name": "UI Refresh" } }, "values": { "ui_refresh": { "_variants": [ { "attributeValues": { "dark_mode_support": true }, "enabled": true, "name": "QA", "rule": "(ends_with $email \"qa-testers.mycompany.com\")" }, { "attributeValues": { "dark_mode_support": true }, "enabled": true, "name": "Beta Testers", "rule": "(exists key::\"opted_in_to_beta\")" }, { "attributeValues": { "dark_mode_support": false }, "enabled": true, "name": "Sample Population", "rule": "(split pct::10 by::$email)" }, { "attributeValues": { "dark_mode_support": false }, "enabled": false, "name": "Default Variant" } ] } }, "version": "1" } ``` 1. `CreateHostedConfigurationVersion` API を使用して、機能フラグの設定データを AWS AppConfigに保存します。 ------ #### [ Linux ] ``` aws appconfig create-hosted-configuration-version \ --application-id APPLICATION_ID \ --configuration-profile-id CONFIGURATION_PROFILE_ID \ --content-type "application/json" \ --content file://path/to/feature_flag_configuration_data.json \ --cli-binary-format raw-in-base64-out \ outfile ``` ------ #### [ Windows ] ``` aws appconfig create-hosted-configuration-version ^ --application-id APPLICATION_ID ^ --configuration-profile-id CONFIGURATION_PROFILE_ID ^ --content-type "application/json" ^ --content file://path/to/feature_flag_configuration_data.json ^ --cli-binary-format raw-in-base64-out ^ outfile ``` ------ #### [ PowerShell ] ``` New-APPCHostedConfigurationVersion ` -ApplicationId APPLICATION_ID ` -ConfigurationProfileId CONFIGURATION_PROFILE_ID ` -ContentType "application/json" ` -Content file://path/to/feature_flag_configuration_data.json ` -Raw ``` ------ `service_returned_content_file` には、 AWS AppConfig 生成されたメタデータを含む設定データが含まれています。 **注記** ホストされた設定バージョンを作成すると、 AWS AppConfig はデータが [https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-type-reference-feature-flags.html](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-type-reference-feature-flags.html) JSON スキーマに準拠していることを確認します。 AWS AppConfig さらに、 は、データ内の各機能フラグ属性が、それらの属性に定義した制約を満たしていることを確認します。 # AWS.AppConfig.FeatureFlags のタイプリファレンスを理解する `AWS.AppConfig.FeatureFlags` JSON スキーマを、機能フラグの設定データを作成するためのリファレンスとして使用します。 ``` { "$schema": "http://json-schema.org/draft-07/schema#", "definitions": { "flagSetDefinition": { "type": "object", "properties": { "version": { "$ref": "#/definitions/flagSchemaVersions" }, "flags": { "$ref": "#/definitions/flagDefinitions" }, "values": { "$ref": "#/definitions/flagValues" } }, "required": ["version"], "additionalProperties": false }, "flagDefinitions": { "type": "object", "patternProperties": { "^[a-z][a-zA-Z\\d_-]{0,63}$": { "$ref": "#/definitions/flagDefinition" } }, "additionalProperties": false }, "flagDefinition": { "type": "object", "properties": { "name": { "$ref": "#/definitions/customerDefinedName" }, "description": { "$ref": "#/definitions/customerDefinedDescription" }, "_createdAt": { "type": "string" }, "_updatedAt": { "type": "string" }, "_deprecation": { "type": "object", "properties": { "status": { "type": "string", "enum": ["planned"] }, "date": { "type": "string", "format": "date" } }, "additionalProperties": false }, "attributes": { "$ref": "#/definitions/attributeDefinitions" } }, "additionalProperties": false }, "attributeDefinitions": { "type": "object", "patternProperties": { "^[a-z][a-zA-Z\\d_-]{0,63}$": { "$ref": "#/definitions/attributeDefinition" } }, "maxProperties": 25, "additionalProperties": false }, "attributeDefinition": { "type": "object", "properties": { "description": { "$ref": "#/definitions/customerDefinedDescription" }, "constraints": { "oneOf": [ { "$ref": "#/definitions/numberConstraints" }, { "$ref": "#/definitions/stringConstraints" }, { "$ref": "#/definitions/arrayConstraints" }, { "$ref": "#/definitions/boolConstraints" } ] } }, "additionalProperties": false }, "flagValues": { "type": "object", "patternProperties": { "^[a-z][a-zA-Z\\d_-]{0,63}$": { "$ref": "#/definitions/flagValue" } }, "additionalProperties": false }, "flagValue": { "type": "object", "properties": { "enabled": { "type": "boolean" }, "_createdAt": { "type": "string" }, "_updatedAt": { "type": "string" }, "_variants": { "type": "array", "maxLength": 32, "items": { "$ref": "#/definitions/variant" } } }, "patternProperties": { "^[a-z][a-zA-Z\\d_-]{0,63}$": { "$ref": "#/definitions/attributeValue", "maxProperties": 25 } }, "additionalProperties": false }, "attributeValue": { "oneOf": [ { "type": "string", "maxLength": 1024 }, { "type": "number" }, { "type": "boolean" }, { "type": "array", "oneOf": [ { "items": { "type": "string", "maxLength": 1024 } }, { "items": { "type": "number" } } ] } ], "additionalProperties": false }, "stringConstraints": { "type": "object", "properties": { "type": { "type": "string", "enum": ["string"] }, "required": { "type": "boolean" }, "pattern": { "type": "string", "maxLength": 1024 }, "enum": { "type": "array", "maxLength": 100, "items": { "oneOf": [ { "type": "string", "maxLength": 1024 }, { "type": "integer" } ] } } }, "required": ["type"], "not": { "required": ["pattern", "enum"] }, "additionalProperties": false }, "numberConstraints": { "type": "object", "properties": { "type": { "type": "string", "enum": ["number"] }, "required": { "type": "boolean" }, "minimum": { "type": "integer" }, "maximum": { "type": "integer" } }, "required": ["type"], "additionalProperties": false }, "arrayConstraints": { "type": "object", "properties": { "type": { "type": "string", "enum": ["array"] }, "required": { "type": "boolean" }, "elements": { "$ref": "#/definitions/elementConstraints" } }, "required": ["type"], "additionalProperties": false }, "boolConstraints": { "type": "object", "properties": { "type": { "type": "string", "enum": ["boolean"] }, "required": { "type": "boolean" } }, "required": ["type"], "additionalProperties": false }, "elementConstraints": { "oneOf": [ { "$ref": "#/definitions/numberConstraints" }, { "$ref": "#/definitions/stringConstraints" } ] }, "variant": { "type": "object", "properties": { "enabled": { "type": "boolean" }, "name": { "$ref": "#/definitions/customerDefinedName" }, "rule": { "type": "string", "maxLength": 16384 }, "attributeValues": { "type": "object", "patternProperties": { "^[a-z][a-zA-Z\\d_-]{0,63}$": { "$ref": "#/definitions/attributeValue" } }, "maxProperties": 25, "additionalProperties": false } }, "required": ["name", "enabled"], "additionalProperties": false }, "customerDefinedName": { "type": "string", "pattern": "^[^\\n]{1,64}$" }, "customerDefinedDescription": { "type": "string", "maxLength": 1024 }, "flagSchemaVersions": { "type": "string", "enum": ["1"] } }, "type": "object", "$ref": "#/definitions/flagSetDefinition", "additionalProperties": false } ``` **重要** 機能フラグ設定データを取得するには、アプリケーションが `GetLatestConfiguration` API を呼び出す必要があります。`GetConfiguration` は廃止されたため、呼び出しても機能フラグ設定データを取得できません。詳細については、*AWS AppConfig API リファレンス*の [GetLatestConfiguration](https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_GetLatestConfiguration.html) を参照してください。 アプリケーションが [GetLatestConfiguration](https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_GetLatestConfiguration.html) を呼び出して、新しくデプロイされた設定を受信すると、機能フラグと属性を定義する情報が削除されます。簡略化された JSON には、指定された各フラグキーに一致するキーマップが含まれています。簡略化された JSON には、`enabled` 属性の `true` または `false` のマッピング値も含まれています。フラグが 、`enabled`から`true`に設定されている場合、そのフラグの属性も存在することになる。この JSON スキーマは、JSON 出力の形式を記述します。 ``` { "$schema": "http://json-schema.org/draft-07/schema#", "type": "object", "patternProperties": { "^[a-z][a-zA-Z\\d_-]{0,63}$": { "$ref": "#/definitions/attributeValuesMap" } }, "additionalProperties": false, "definitions": { "attributeValuesMap": { "type": "object", "properties": { "enabled": { "type": "boolean" } }, "required": ["enabled"], "patternProperties": { "^[a-z][a-zA-Z\\d_-]{0,63}$": { "$ref": "#/definitions/attributeValue" } }, "maxProperties": 25, "additionalProperties": false }, "attributeValue": { "oneOf": [ { "type": "string","maxLength": 1024 }, { "type": "number" }, { "type": "boolean" }, { "type": "array", "oneOf": [ { "items": { "oneOf": [ { "type": "string", "maxLength": 1024 } ] } }, { "items": { "oneOf": [ { "type": "number" } ] } } ] } ], "additionalProperties": false } } } ``` # 機能フラグの以前のバージョンを新しいバージョンに保存する 機能フラグを更新すると、 は変更を新しいバージョン AWS AppConfig に自動的に保存します。機能フラグの以前のバージョンを使用する場合は、ドラフトバージョンにコピーしてから保存する必要があります。機能フラグの以前のバージョンは、新しいバージョンとして保存しない限り、編集して変更を保存することはできません。 **機能フラグの以前のバージョンを編集して新しいバージョンに保存するには** 1. [https://console.aws.amazon.com/systems-manager/appconfig/](https://console.aws.amazon.com/systems-manager/appconfig/) で AWS Systems Manager コンソールを開きます。 1. ナビゲーションペインで、**[アプリケーション]** を選択し、編集して新しいバージョンに保存する機能フラグを持つアプリケーションを選択します。 1. **[設定プロファイルと機能フラグ]** タブで、編集して新しいバージョンに保存する機能フラグを持つ設定プロファイルを選択します。 1. **[機能フラグ]** タブで、**[バージョン]** リストを使用して、編集して新しいバージョンに保存するバージョンを選択します。 1. **[ドラフトバージョンにコピー]** を選択します。 1. **[バージョンラベル]** フィールドに、新しいラベルを入力します (オプションですが、推奨)。 1. **[バージョンの説明]** フィールドに、新しい説明を入力します (オプションですが、推奨)。 1. **[バージョンを保存する]** を選択します。 1. **[デプロイの開始]** を選択して、新しいバージョンをデプロイします。 # での無料フォーム設定プロファイルの作成 AWS AppConfig *設定データ*は、アプリケーションの動作に影響する設定のコレクションです。*設定プロファイル*には、 がその保存場所に設定データを見つけ AWS AppConfig られるようにする URI と設定タイプが含まれます。フリーフォーム設定プロファイルを使用すると、 AWS AppConfig ホストされた設定ストア、または次のいずれかの AWS のサービス および Systems Manager ツールにデータを保存できます。 **** | ロケーション | サポートされているファイルの種類 | | --- | --- | | AWS AppConfig ホスト設定ストア | を使用して追加した場合は、YAML、JSON、およびテキスト AWS マネジメントコンソール。 AWS AppConfig [CreateHostedConfigurationVersion](https://docs.aws.amazon.com/appconfig/2019-10-09/APIReference/API_CreateHostedConfigurationVersion.html) API アクションを使用して追加された場合の任意のファイルタイプ。 | | [Amazon Simple Storage Service (Amazon S3)](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Welcome.html) | いずれか | | [AWS CodePipeline](https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html) | パイプライン (サービスによって定義される) | | [AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html) | シークレット (サービスによって定義される) | | [AWS Systems Manager パラメータストア](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html) | 標準で安全な文字列パラメータ (Parameter Store で定義される) | | [AWS Systems Manager ドキュメントストア (SSM ドキュメント)](https://docs.aws.amazon.com/systems-manager/latest/userguide/documents.html) | YAML、JSON、テキスト | 設定プロファイルには、設定データが構文的および意味的に正しいことを確認するためのオプションのバリデータを含めることもできます。 は、デプロイの開始時にバリデータを使用してチェック AWS AppConfig を実行します。エラーが検出されると、設定のターゲットに変更が加えられる前にデプロイが停止します。 **注記** 可能な限り、ホストされた設定ストアで設定データをホストすることをお勧めします。ホスト AWS AppConfig された設定ストアは、ほとんどの機能と機能強化を提供します。 AWS AppConfig ホストされた設定ストアまたは SSM ドキュメントに保存されているフリーフォーム設定の場合、設定プロファイルの作成時に Systems Manager コンソールを使用してフリーフォーム設定を作成できます。このプロセスについては、このトピックの後半で説明します。 Parameter Store、Secrets Manager または Amazon S3 に格納されているフリーフォーム設定の場合は、まずパラメータ、シークレット、またはオブジェクトを作成してから、関連する設定ストアに格納する必要があります。設定データを保存したら、このトピックの手順を使用して設定プロファイルを作成できます。 **Topics** + [バリデータを理解する](appconfig-creating-configuration-and-profile-validators.md) + [設定ストアのクォータと制限について](appconfig-creating-configuration-and-profile-quotas.md) + [AWS AppConfig ホストされた設定ストアについて](appconfig-creating-configuration-and-profile-about-hosted-store.md) + [Amazon S3 に保存されている設定について](appconfig-creating-configuration-and-profile-S3-source.md) + [AWS AppConfig フリーフォーム設定プロファイルの作成 (コンソール)](appconfig-creating-free-form-configuration-and-profile-create-console.md) + [AWS AppConfig フリーフォーム設定プロファイルの作成 (コマンドライン)](appconfig-creating-free-form-configuration-and-profile-create-commandline.md) # バリデータを理解する 設定プロファイルを作成する場合、最大 2 つのバリデータを指定できます。バリデータは、設定データが構文的かつ意味的に正しいことを保証します。バリデータを使用する場合は、設定プロファイルを作成する前に作成する必要があります。 は、次のタイプのバリデータ AWS AppConfig をサポートしています。 + **AWS Lambda 関数**: 機能フラグとフリーフォーム設定でサポートされています。 + **JSON スキーマ**: フリーフォーム設定でサポートされています (JSON スキーマに対して機能フラグAWS AppConfig を自動的に検証します）。 **Topics** + [AWS Lambda 関数の検証](#appconfig-creating-configuration-and-profile-validators-lambda) + [JSON スキーマバリデータ](#appconfig-creating-configuration-and-profile-validators-json-schema) ## AWS Lambda 関数の検証 Lambda 関数バリデータは、次のイベントスキーマで設定する必要があります。 AWS AppConfig はこのスキーマを使用して Lambda 関数を呼び出します。内容は base64 でエンコードされた文字列で、URI は文字列です。 ``` { "applicationId": "The application ID of the configuration profile being validated", "configurationProfileId": "The ID of the configuration profile being validated", "configurationVersion": "The version of the configuration profile being validated", "content": "Base64EncodedByteString", "uri": "The configuration uri" } ``` AWS AppConfig は、レスポンスで Lambda `X-Amz-Function-Error`ヘッダーが設定されていることを確認します。Lambda は、関数が例外をスローした場合にこのヘッダーを設定します。`X-Amz-Function-Error` の詳細については、「*AWS Lambda デベロッパーガイド*」の「[エラー処理と AWS Lambdaでの自動再試行](https://docs.aws.amazon.com/lambda/latest/dg/retries-on-errors.html)」を参照してください。 検証を成功させる Lambda 応答コードの簡単な例を以下に示します。 ``` import json def handler(event, context): #Add your validation logic here print("We passed!") ``` 検証を失敗させる Lambda 応答コードの簡単な例を以下に示します。 ``` def handler(event, context): #Add your validation logic here raise Exception("Failure!") ``` 設定パラメータが素数の場合にのみ有効とする、別の例を次に示します。 ``` function isPrime(value) { if (value < 2) { return false; } for (i = 2; i < value; i++) { if (value % i === 0) { return false; } } return true; } exports.handler = async function(event, context) { console.log('EVENT: ' + JSON.stringify(event, null, 2)); const input = parseInt(Buffer.from(event.content, 'base64').toString('ascii')); const prime = isPrime(input); console.log('RESULT: ' + input + (prime ? ' is' : ' is not') + ' prime'); if (!prime) { throw input + "is not prime"; } } ``` AWS AppConfig は、 `StartDeployment`および `ValidateConfigurationActivity` API オペレーションを呼び出すときに検証 Lambda を呼び出します。Lambda を呼び出すには、`appconfig.amazonaws.com` アクセス許可を提供する必要があります。詳細については、[AWS 「Services](https://docs.aws.amazon.com/lambda/latest/dg/access-control-resource-based.html#permissions-resource-serviceinvoke). AWS AppConfig limits the validation Lambda run time to 15 seconds, including start-up latency」を参照してください。 ## JSON スキーマバリデータ SSM ドキュメントで設定を作成する場合は、その設定の JSON スキーマを指定または作成する必要があります。JSON スキーマは、アプリケーション構成設定ごとに許可されるプロパティを定義します。この JSON スキーマは、新規または更新された構成設定がアプリケーションに必要なベストプラクティスに準拠するようにするための一連のルールのように機能します。以下はその例です。 ``` { "$schema": "http://json-schema.org/draft-04/schema#", "title": "$id$", "description": "BasicFeatureToggle-1", "type": "object", "additionalProperties": false, "patternProperties": { "[^\\s]+$": { "type": "boolean" } }, "minProperties": 1 } ``` SSM ドキュメントから設定を作成すると、その設定がスキーマの要件を満たしているかどうかをシステムが自動的に検証します。そうでない場合は、 AWS AppConfig は、検証エラーを返します。 **重要** JSON スキーマ検証ツールについては、次の重要事項に留意してください。　　　　　　　　　　　　　　　　　　　 SSM ドキュメントに保存された設定データは、設定をシステムに追加する前に、関連付けられた JSON スキーマに対して検証する必要があります。SSM パラメータには検証方法は必要ありませんが、 を使用して新規または更新された SSM パラメータ設定の検証チェックを作成することをお勧めします AWS Lambda。 SSM ドキュメントの設定では `ApplicationConfiguration` ドキュメントタイプを使用します。対応する JSON スキーマは `ApplicationConfigurationSchema` ドキュメントタイプを使用します。 AWS AppConfig は、インラインスキーマの JSON スキーマバージョン 4.X をサポートしています。アプリケーション設定で JSON スキーマの異なるバージョンが必要な場合は、Lambda バリデータを作成する必要があります。 # 設定ストアのクォータと制限について でサポートされている設定ストア AWS AppConfig には、次のクォータと制限があります。 **** | | AWS AppConfig ホスト設定ストア | Amazon S3 | Systems Manager Parameter Store | AWS Secrets Manager | Systems Manager ドキュメント・ストア | AWS CodePipeline | | --- | --- | --- | --- | --- | --- | --- | | **設定サイズの制限** | デフォルト 2 MB、最大 4 MB | 2 MB S3 ではなく AWS AppConfigによって強制される | 4 KB (無料利用枠)/8 KB (詳細パラメータ) | 64 KB | 64 KB | 2 MBCodePipeline ではなく AWS AppConfigによって強制される | | **リソースストレージの制限** | 1 GB | 無制限 | 10,000 パラメータ (無料利用枠)/100,000 パラメータ (詳細パラメータ) | 500,000 | 500 ドキュメント | アプリケーションごとの設定プロファイルの数によって制限される (アプリケーションあたり 100 プロファイル) | | **サーバー側の暗号化** | はい | [SSE-S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html)、[SSE-KMS](https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html) | はい | あり | なし | はい | | **CloudFormation ** のサポート | はい | データの作成または更新用ではありません | はい | あり | なし | はい | | **料金** | 空き | 「[Amazon S3 の料金](https://aws.amazon.com//s3/pricing/)」を参照してください | 「[AWS Systems Manager 料金表](https://aws.amazon.com//systems-manager/pricing/)」を参照してください | 「[AWS Secrets Manager 料金表](https://aws.amazon.com//secrets-manager/pricing/)」を参照してください | 空き | 「[AWS CodePipeline 料金表](https://aws.amazon.com//codepipeline/pricing/)」を参照してください | # AWS AppConfig ホストされた設定ストアについて AWS AppConfig には、内部設定ストアまたはホスト設定ストアが含まれています。設定は 2 MB 以下である必要があります。 AWS AppConfig ホストされた設定ストアには、他の設定ストアオプションよりも以下の利点があります。 + Amazon Simple Storage Service (Amazon S3) やパラメータストアなど、他のサービスをセットアップして設定する必要はありません。 + 設定ストアを使用するには AWS Identity and Access Management 、(IAM) アクセス許可を設定する必要はありません。 + 設定を YAML、JSON、またはテキストドキュメントとして保存できます。 + ストアを使用してもコストは発生しません。 + 構成プロファイルを作成したら、作成した構成をストアに追加できます。 # Amazon S3 に保存されている設定について 設定は、Amazon Simple Storage Service (Amazon S3) バケットに保存できます。設定プロファイルの作成時には、バケット内の 1 つの S3 オブジェクトの URI を指定します。オブジェクトを取得するアクセス許可を付与 AWS AppConfig する AWS Identity and Access Management (IAM) ロールの Amazon リソースネーム (ARN) も指定します。Amazon S3 オブジェクトの設定プロファイルを作成する場合は、次の制限事項に注意してください。 **** | 制限 | 詳細 | | --- | --- | | サイズ | S3 オブジェクトとして保存できる設定のサイズは最大 1 MB です。 | | オブジェクト暗号化 | 設定プロファイルは、SSE-S3 と SSE-KMS で暗号化されたオブジェクトを対象にすることができます。 | | ストレージクラス | AWS AppConfig は、次の S3 ストレージクラスをサポートします: `STANDARD`、`INTELLIGENT_TIERING`、`REDUCED_REDUNDANCY`、`STANDARD_IA`、`ONEZONE_IA`。すべての S3 Glacier クラス (`GLACIER` および `DEEP_ARCHIVE`) はサポートしていません。 | | バージョニング | AWS AppConfig では、S3 オブジェクトがバージョニングを使用する必要があります。 | ## Amazon S3 オブジェクトとして保存する設定のアクセス許可の設定 S3 オブジェクトとして保存されている設定の設定プロファイルを作成するときは、オブジェクトを取得する AWS AppConfig アクセス許可を付与する IAM ロールの ARN を指定する必要があります。このロールには、以下のアクセス許可が含まれている必要があります。 S3 オブジェクトに対するアクセス許可 + s3:GetObject + s3:GetObjectVersion S3 オブジェクトを一覧表示するアクセス許可 s3:ListAllMyBuckets オブジェクトを保存する S3 バケットへのアクセス許可 + s3:GetBucketLocation + s3:GetBucketVersioning + s3:ListBucket + s3:ListBucketVersions が S3 オブジェクトに保存されている設定 AWS AppConfig を取得できるようにするロールを作成するには、次の手順を実行します。 **S3 オブジェクトにアクセスするための IAM ポリシーの作成** 次の手順を使用して、 が S3 オブジェクトに保存されている設定 AWS AppConfig を取得できるようにする IAM ポリシーを作成します。 **S3 オブジェクトにアクセスするための IAM ポリシーを作成するには** 1. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で IAM コンソール を開きます。 1. ナビゲーションペインで **ポリシー**を選択してから **ポリシーの作成**を選択します。 1. **ポリシーの作成** ページで、**JSON** タブを選択します。 1. S3 バケットおよび設定オブジェクトについての情報を、次のサンプルポリシーで更新します。次に、そのポリシーを **JSON** タブのテキストフィールドに貼り付けます。*プレースホルダー値*を、ユーザー自身の情報に置き換えます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:GetObjectVersion" ], "Resource": "arn:aws:s3:::amzn-s3-demo-bucket/my-configurations/my-configuration.json" }, { "Effect": "Allow", "Action": [ "s3:GetBucketLocation", "s3:GetBucketVersioning", "s3:ListBucketVersions", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket" ] }, { "Effect": "Allow", "Action": "s3:ListAllMyBuckets", "Resource": "*" } ] } ``` ------ 1. **[ポリシーの確認]** を選択します。 1. **レビューポリシー** ページの **名前** ボックスに名前を入力し、続いて説明を入力します。 1. **ポリシーの作成** を選択します。**ロール**ページが再度表示されます。 **S3 オブジェクトにアクセスするための IAM ロールの作成** 次の手順を使用して、 が S3 オブジェクトに保存されている設定を取得 AWS AppConfig できるようにする IAM ロールを作成します。 **Amazon S3 オブジェクトにアクセスするための IAM ポリシーを作成するには** 1. IAM コンソール ([https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)) を開きます。 1. ナビゲーションペインで **ロール**を選択してから、**ロールを作成する** を選択します。 1. **信頼するエンティティのタイプを選択** で **AWS サービス** ( ) を選択します。 1. **ユースケースの選択** セクションの **一般的ユースケース** で **EC2** を選択して、**次へ: アクセス許可** を選択します。 1. **アクセス権限ポリシーをアタッチする** ページで、検索ボックスに前の手順で作成したポリシーの名前を入力します。 1. ポリシーを選択して、**次へ: タグ** を選択します。 1. **タグ (オプショナル) の追加** ページでキーと任意の値を入力して、**次へ: 確認** を選択します。 1. **確認** ページの **ロール名** フィールドに名前を入力し、続いて説明を入力します。 1. **ロールを作成する**を選択します。**ロール**ページが再度表示されます。 1. **ロール** ページで作成したロールを選択して、**概要** ページを開きます。**ロール名** と **ロール ARN** を書き留めます。このロール ARN は、このトピックで後述する設定プロファイルの作成時に指定します。 **信頼関係の作成** 次の手順を使用して、先ほど作成したロールが AWS AppConfigを信頼するように設定します。 **信頼関係を追加するには** 1. 作成したロールの **概要** ページで **信頼関係** タブを選択し、**信頼関係の編集** を選択します。 1. 次の例に示すように、`"ec2.amazonaws.com"` を削除して `"appconfig.amazonaws.com"` を追加します。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "appconfig.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } ``` ------ 1. **信頼ポリシーの更新** を選択します。 # AWS AppConfig フリーフォーム設定プロファイルの作成 (コンソール) AWS Systems Manager コンソールを使用して AWS AppConfig 、フリーフォーム設定プロファイルと (オプションで) フリーフォーム設定を作成するには、次の手順に従います。 **フリーフォーム設定プロファイルを作成するには** 1. [https://console.aws.amazon.com/systems-manager/appconfig/](https://console.aws.amazon.com/systems-manager/appconfig/) で AWS Systems Manager コンソールを開きます。 1. ナビゲーションペインで、**[アプリケーション]** を選択し、[でのアプリケーションの名前空間の作成 AWS AppConfig](appconfig-creating-namespace.md) で作成したアプリケーションを選択します。 1. **[設定プロファイルと機能フラグ]** タブを選択し、**[設定を作成]** を選択します。 1. **[設定オプション]** セクションで、**[フリーフォーム設定]** を選択します。 1. **[設定プロファイル名]** に設定プロファイルの名前を入力します。 1. (オプション) **[説明]** を展開し、説明を入力します。 1. (オプション) **[追加オプション]** を展開し、必要に応じて以下を完了します。 1. **[拡張機能を関連付ける]** セクションで、リストから拡張機能を選択します。 1. **[タグ]** セクションで、**[新しいタグを追加]** を選択し、キーとオプションの値を指定します。 1. [**次へ**] を選択します。 1. **[設定データを指定する]** ページの **[設定の定義]** セクションで、オプションを選択します。 1. 次の表の説明に従って、選択したオプションのフィールドに入力します。 **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/appconfig/latest/userguide/appconfig-creating-free-form-configuration-and-profile-create-console.html) 1. **サービスロール**セクションで、**新しいサービスロール**を選択して、設定データへのアクセスを提供する IAM ロール AWS AppConfig を作成します。 は、前に入力した名前に基づいて**ロール名**フィールド AWS AppConfig を自動的に入力します。または、**[既存のサービスロール]** を選択します。**ロール ARN** リストを使用してロールを選択します。 1. オプションで、**[検証ツールを追加]** ページで、**[JSON スキーマ]** または **[AWS Lambda]** を選択します。**JSON スキーマ** を選択した場合、フィールドに JSON スキーマを入力します。**AWS Lambda** を選択した場合は、リストから関数 Amazon リソースネーム (ARN) とバージョンを選択します。 **重要** SSM ドキュメントに保存された設定データは、設定をシステムに追加する前に、関連付けられた JSON スキーマに対して検証する必要があります。SSM パラメータには検証方法は必要ありませんが、 を使用して新規または更新された SSM パラメータ設定の検証チェックを作成することをお勧めします AWS Lambda。 1. [**次へ**] を選択します。 1. **[確認して保存]** ページで、**[保存してデプロイを続ける]** を選択します。 **重要** の設定プロファイルを作成した場合は AWS CodePipeline、*デプロイプロバイダー* AWS AppConfig として を指定するパイプラインを CodePipeline で作成する必要があります。[に機能フラグと設定データをデプロイする AWS AppConfig](deploying-feature-flags.md) を実行する必要はありません。ただし、「[AWS AppConfig エージェントを使用せずに設定データを取得する](about-data-plane.md)」で説明されているように、アプリケーション設定の更新を受け取るようにクライアントを設定する必要があります。をデプロイプロバイダー AWS AppConfig として指定するパイプラインの作成については、 *AWS CodePipeline ユーザーガイド*の[「チュートリアル: デプロイプロバイダー AWS AppConfig として を使用するパイプラインを作成する](https://docs.aws.amazon.com/codepipeline/latest/userguide/tutorials-AppConfig.html)」を参照してください。 [に機能フラグと設定データをデプロイする AWS AppConfig](deploying-feature-flags.md) に進みます。 # AWS AppConfig フリーフォーム設定プロファイルの作成 (コマンドライン) 次の手順では、 AWS CLI (Linux または Windows の場合) または AWS Tools for PowerShell を使用して AWS AppConfig フリーフォーム設定プロファイルを作成する方法について説明します。必要に応じて、 AWS CloudShell を使用して以下のコマンドを実行できます。詳細については、*「 AWS CloudShellユーザーガイド」*の[「What is AWS CloudShell ?」](https://docs.aws.amazon.com//cloudshell/latest/userguide/welcome.html)( とは？) を参照してください。 **注記** ホストされた設定ストアで AWS AppConfig ホストされているフリーフォーム設定の場合は、場所 URI `hosted`に を指定します。 **を使用して設定プロファイルを作成するには AWS CLI** 1. を開きます AWS CLI。 1. 次のコマンドを実行して、フリーフォーム設定プロファイルを作成します。 ------ #### [ Linux ] ``` aws appconfig create-configuration-profile \ --application-id APPLICATION_ID \ --name NAME \ --description CONFIGURATION_PROFILE_DESCRIPTION \ --location-uri CONFIGURATION_URI or hosted \ --retrieval-role-arn IAM_ROLE_ARN \ --tags TAGS \ --validators "Content=SCHEMA_CONTENT or LAMBDA_FUNCTION_ARN,Type=JSON_SCHEMA or LAMBDA" ``` ------ #### [ Windows ] ``` aws appconfig create-configuration-profile ^ --application-id APPLICATION_ID ^ --name NAME ^ --description CONFIGURATION_PROFILE_DESCRIPTION ^ --location-uri CONFIGURATION_URI or hosted ^ --retrieval-role-arn IAM_ROLE_ARN ^ --tags TAGS ^ --validators "Content=SCHEMA_CONTENT or LAMBDA_FUNCTION_ARN,Type=JSON_SCHEMA or LAMBDA" ``` ------ #### [ PowerShell ] ``` New-APPCConfigurationProfile ` -Name NAME ` -ApplicationId APPLICATION_ID ` -Description CONFIGURATION_PROFILE_DESCRIPTION ` -LocationUri CONFIGURATION_URI or hosted ` -RetrievalRoleArn IAM_ROLE_ARN ` -Tag TAGS ` -Validators "Content=SCHEMA_CONTENT or LAMBDA_FUNCTION_ARN,Type=JSON_SCHEMA or LAMBDA" ``` ------ **重要** 次の重要な情報に注意してください。 の設定プロファイルを作成した場合は AWS CodePipeline、*デプロイプロバイダー* AWS AppConfig として を指定するパイプラインを CodePipeline で作成する必要があります。[に機能フラグと設定データをデプロイする AWS AppConfig](deploying-feature-flags.md) を実行する必要はありません。ただし、「[AWS AppConfig エージェントを使用せずに設定データを取得する](about-data-plane.md)」で説明されているように、アプリケーション設定の更新を受け取るようにクライアントを設定する必要があります。をデプロイプロバイダー AWS AppConfig として指定するパイプラインの作成については、 *AWS CodePipeline ユーザーガイド*の[「チュートリアル: デプロイプロバイダー AWS AppConfig として を使用するパイプラインを作成する](https://docs.aws.amazon.com/codepipeline/latest/userguide/tutorials-AppConfig.html)」を参照してください。 AWS AppConfig ホストされた設定ストアで設定を作成した場合は、[CreateHostedConfigurationVersion](https://docs.aws.amazon.com//appconfig/2019-10-09/APIReference/API_CreateHostedConfigurationVersion.html) API オペレーションを使用して設定の新しいバージョンを作成できます。この API オペレーション AWS CLI の詳細とサンプルコマンドを表示するには、*AWS CLI 「 コマンドリファレンス*」の[create-hosted-configuration-version](https://docs.aws.amazon.com/cli/latest/reference/appconfig/create-hosted-configuration-version.html)」を参照してください。 [に機能フラグと設定データをデプロイする AWS AppConfig](deploying-feature-flags.md) に進みます。 # 非ネイティブデータソースの設定プロファイルの作成 AWS AppConfig は、ほとんどのデータストアからの設定データのデプロイをサポートしています。ネイティブでは、 AWS AppConfig は次のサービスに保存されている設定データのデプロイをサポートしています。 + AWS AppConfig ホストされた設定ストア + Amazon S3 + AWS Secrets Manager + AWS Systems Manager パラメータストア + Systems Manager ドキュメントストア + AWS CodePipeline 設定データが でネイティブにサポートされていない場所に保存されている場合は AWS AppConfig、 [AWS AppConfig 拡張機能](https://docs.aws.amazon.com/appconfig/latest/userguide/working-with-appconfig-extensions.html)を作成して、そのソースからデータを取得できます。例えば、 AWS AppConfig 拡張機能を使用すると、Amazon Relational Database Service (Amazon RDS)、Amazon DynamoDB (DynamoDB)、GitHub、GitLab、またはローカルリポジトリに保存されている設定データを取得できます。拡張機能を実装することで、アプリケーションとコンピューティング環境 AWS AppConfig のセキュリティと DevOps の機能強化を活用できます。この方法は、設定データをレガシーシステムから AWS AppConfigに移行するときにも使用できます。 AWS AppConfig でネイティブにサポートされていないデータソースの設定プロファイルを作成するには、以下のプロセスまたはアクションを実行する必要があります。 1. データソースからデータを取得する [AWS Lambda 関数](https://docs.aws.amazon.com/lambda/latest/dg/welcome.html)を作成します。Lambda 関数がデータソースにアクセスできる限り、 AWS AppConfig 拡張機能はデータを取得できます。 1. Lambda 関数を呼び出すカスタム AWS AppConfig 拡張機能を作成します。詳細については、「[チュートリアル: カスタム AWS AppConfig 拡張機能の作成](working-with-appconfig-extensions-creating-custom.md)」を参照してください。 1. AWS AppConfig 自由形式の設定プロファイルを作成します。具体的には、**AWS AppConfig でホストされた設定**の定義を使用する設定プロファイルを作成します。設定プロファイルは、Lambda 関数がソースから設定を取得した後、一時的なデータストアとして機能します。アプリケーションは、 AWS AppConfig ホストされた設定ストアから設定データを取得します。詳細については、「[での無料フォーム設定プロファイルの作成 AWS AppConfig](appconfig-free-form-configurations-creating.md)」を参照してください。 1. `PRE_CREATE_HOSTED_CONFIGURATION_VERSION` アクションポイントを使用してトリガーする拡張機能の関連付けを作成します。詳細については、「[ステップ 4: カスタム拡張機能の AWS AppConfig 拡張機能関連付けを作成する](working-with-appconfig-extensions-creating-custom-association.md)」を参照してください。 設定が完了すると、アプリケーションが設定データの新しいバージョンをリクエストする際に、Lambda は設定データを取得し、設定プロファイルにプルします。その後、 AWS AppConfig は設定プロファイルとサードパーティーデータを保存します。 準備ができたら、他のタイプの設定データと同様に、設定プロファイルをアプリケーションにデプロイできます。 **注記** 既存の設定データに沿ってサードパーティーデータを挿入するか、設定データのコンテンツ全体にサードパーティーデータのみを含めるかを選択できます。データを他の既存のデータに合わせる場合、そのロジックはサードパーティーソースからデータをインポートする Lambda 関数の一部である必要があります。 ## レガシーおよび自社開発の設定サービス AWS AppConfig から への移行 の使用を開始し AWS AppConfig 、別のシステムにレガシー設定データまたは機能フラグがある場合は、このトピックで前述したプロセスを使用してレガシーシステムから移行できます AWS AppConfig。レガシーシステムからデータを取得してデプロイする拡張機能を構築できます AWS AppConfig。 AWS AppConfig この方法で を使用すると、レガシーデータストアを引き続き使用しながら、すべての安全ガードレールの制御と利点が得られます。