View a markdown version of this page

API オペレーションでの Amazon Verified Permissions ポリシーストアエイリアスの使用 - Amazon Verified Permissions
オペレーションでのポリシーストアエイリアスの使用全体でのポリシーストアエイリアスの使用 AWS リージョンポリシーストアエイリアスはトラフィック制御メカニズムではありませんダウンタイムのないポリシーストアの変更の実行

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

API オペレーションでの Amazon Verified Permissions ポリシーストアエイリアスの使用

IsAuthorized、IsAuthorizedWithToken、GetPolicyStore などのpolicyStoreIdパラメータを受け入れる Amazon Verified Permissions オペレーションは、ポリシーストア ID の代わりにポリシーストアエイリアス名を受け入れることができます。

重要

ポリシーストアエイリアスをpolicyStoreIdパラメータの値として使用する場合は、 policy-store-alias/ プレフィックスを含める必要があります。たとえば、 policy-store-alias/example-policy-storeではなく を使用しますexample-policy-store。

オペレーションでのポリシーストアエイリアスの使用

次のIsAuthorizedコマンドは、 という名前のポリシーストアエイリアスexample-policy-storeを使用してポリシーストアを識別します。

AWS CLI
$ aws verifiedpermissions is-authorized \
    --policy-store-id policy-store-alias/example-policy-store \
    --principal entityType=User,entityId=alice \
    --action actionType=Action,actionId=view \
    --resource entityType=Photo,entityId=photo123
注記

DeletePolicyStore オペレーションの policyStoreIdフィールドの代わりにポリシーストアエイリアスを使用することはできません。

全体でのポリシーストアエイリアスの使用 AWS リージョン

エイリアスの最も強力な使用法の 1 つは、アプリケーションを複数の AWS リージョンで実行する場合です。たとえば、各リージョンで異なるポリシーストアを使用するグローバルアプリケーションがあるとします。

  • us-east-1 では、 を使用しますPSEXAMPLEabcdefg111111。

  • eu-west-1 では、 を使用しますPSEXAMPLEabcdefg222222。

各リージョンで異なるバージョンのアプリケーションを作成することも、ディクショナリステートメントまたはスイッチステートメントを使用して各リージョンに適したポリシーストアを選択することもできます。ただし、各リージョンで同じポリシーストアエイリアス名を持つポリシーストアエイリアスを作成する方がはるかに簡単です。ポリシーストアのエイリアス名では大文字と小文字が区別されることに注意してください。

AWS CLI
$ aws --region us-east-1 verifiedpermissions create-policy-store-alias \
    --alias-name policy-store-alias/my-app \
    --policy-store-id PSEXAMPLEabcdefg111111

$ aws --region eu-west-1 verifiedpermissions create-policy-store-alias \
    --alias-name policy-store-alias/my-app \
    --policy-store-id PSEXAMPLEabcdefg222222

次に、コードでポリシーストアエイリアスを使用します。コードが各リージョンで実行されると、ポリシーストアエイリアスはそのリージョン内の関連するポリシーストアを参照します。

AWS CLI
$ aws verifiedpermissions is-authorized \
    --policy-store-id policy-store-alias/my-app \
    --principal entityType=User,entityId=alice \
    --action actionType=Action,actionId=view \
    --resource entityType=Photo,entityId=photo123

ただし、ポリシーストアのエイリアスが削除されるリスクがあります。この場合、アプリケーションがポリシーストアのエイリアス名を使用しようとすると失敗し、ポリシーストアのエイリアスを再作成または更新する必要がある場合があります。このリスクを軽減するには、アプリケーションで使用するポリシーストアエイリアスを管理するアクセス許可をプリンシパルに付与することに注意が必要です。

ポリシーストアエイリアスはトラフィック制御メカニズムではありません

ポリシーストアエイリアスは、ポリシーストアの安定したわかりやすい名前です。これは、ポリシーストア間で認可トラフィックをシフト、分割、または重み付けするためのメカニズムではありません。Lambda エイリアスなど、リソースのバージョン間でトラフィックをルーティングする機能に精通している場合は、ポリシーストアエイリアスが同じように動作しないことに注意してください。設計上、ポリシーストアエイリアスは AWS KMS キーエイリアスに近く、リソースの前にルーティングレイヤーではなく、リソースに永続的な名前を提供します。

このため、意図的に UpdatePolicyStoreAliasオペレーションを提供しません。ポリシーストアエイリアスが指すポリシーストアを変更するには、ポリシーストアエイリアスを削除し、同じ名前で別のポリシーストアをターゲットとする新しいポリシーストアエイリアスを作成します。これはアトミックオペレーションではなく、トラフィック制御メカニズムが保証するものではありません。

ポリシーストアエイリアスが解決するポリシーストアを変更しても、その変更はすべての場所で同時に有効になるわけではありません。

  • 更新されたマッピングは、コントロールプレーンから認可リクエストを評価するデータプレーンに伝播する必要があります。マッピングは瞬時には伝達されません。

  • ポリシーストアのエイリアス解決は結果整合性があり、キャッシュできるため、変更後に移行ウィンドウが存在します。この期間中、以前に関連付けたポリシーストアは一部のリクエストを処理し、新しく関連付けたポリシーストアは他のリクエストを処理します。このウィンドウの長さは不確定です。

この期間中、アプリケーションはいずれかのポリシーストアから認可決定を受け取ることができます。異なるポリシーストアには異なるポリシー、エンティティ、スキーマを含めることができるため、同じリクエストは、どのポリシーストアが提供するかに応じて異なる決定を生成できます。したがって、ポリシーストアエイリアスは、ポリシーストア間のアトミックカットオーバーを提供できず、デプロイ戦略やトラフィック管理戦略に代わるものではありません。

エイリアスをカットオーバーメカニズムとして使用しない

1 つのポリシーストアから別のポリシーストアに認可トラフィックを切り替えるために、ポリシーストアエイリアスを再ポイントする高レベルの infrastructure-as-code プリミティブまたはデプロイプリミティブを構築しないでください。変更はアトミックではないため、不確定な期間、両方のポリシーストアに対して同時にリクエストを承認できます。これにより、承認の決定に一貫性がなくなる可能性があります。ポリシーストアを安全に切り替えるには、「」を参照してくださいダウンタイムのないポリシーストアの変更の実行。

ダウンタイムのないポリシーストアの変更の実行

ポリシーストアエイリアスはアトミックカットオーバーを提供しないため (「」を参照ポリシーストアエイリアスはトラフィック制御メカニズムではありません)、ポリシーストアエイリアスを再ポイントして、あるポリシーストアから別のポリシーストアに移行しないことをお勧めします。代わりに、アプリケーション内からの移行を制御して、新しいポリシーストアを検証し、必要に応じてすぐにロールバックできるようにします。次のアプローチでは、ダウンタイムなしでポリシーストアを切り替えることができます。

  1. 新しいポリシーストアを作成し、独自のポリシーストアエイリアスを付与します。これにより、現在のポリシーストアと新しいポリシーストアにはそれぞれ異なる安定した名前が付けられます。たとえば、現在のポリシーストアをpolicy-store-alias/example-policy-store指し続け、新しいポリシーストアpolicy-store-alias/example-policy-store-2用に を作成します。1 つのポリシーストアエイリアスを再利用または再ポイントして切り替えを実行しないでください。

  2. ポリシー、スキーマ、およびその他の設定を新しいポリシーストアにレプリケートし、現在のポリシーストアと並行して実行します。

  3. アプリケーションに設定値または機能フラグを追加し (AppConfig を使用するなど）、どのポリシーストアエイリアスが認可の決定に信頼できるかを決定します。トラフィックを切り替えるためにエイリアス自体を変更しないでください。

  4. シャドウモードで新しいポリシーストアを実行します。両方のポリシーストアに同じ IsAuthorizedまたは IsAuthorizedWithTokenリクエストを送信し、決定を比較します。新しいポリシーストアが期待される決定を返すまで、不一致を記録して調査します。

  5. 機能フラグを使用して、認可の決定を新しいポリシーストアエイリアスに段階的にシフトします。たとえば、アプリケーションホストまたはユーザーセグメント間で段階的にロールアウトする場合などです。承認の決定とエラー率をモニタリングして続行します。

  6. 問題を検出した場合は、 機能フラグを使用して、すぐに元のポリシーストアエイリアスに戻ります。アプリケーションはスイッチを制御するため、ロールバックは即時であり、エイリアスの伝播に依存しません。

  7. 新しいポリシーストアが完全に検証され、すべてのトラフィックを処理した後、古いポリシーストアとそのポリシーストアエイリアスを廃止します。

このパターンにより、エイリアス伝達ではなく、アプリケーションが各リクエストを処理するポリシーストアを制御できます。このコントロールは、移行を安全かつ元に戻すものであり、ポリシーストアエイリアスを再ポイントすると導入される移行ウィンドウを回避します。