AND/OR ロジック - Amazon Simple Notification Service

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

AND/OR ロジック

AND/OR ロジックを含むオペレーションを使用してメッセージ属性またはメッセージ本文と一致させることができます。

AND ロジック

複数のプロパティ名を使用して AND ロジックを適用できます。

次のポリシーについて考えます。

{ "customer_interests": ["rugby"], "price_usd": [{"numeric": [">", 100]}] }

このポリシーは、customer_interests の値が rugby に設定され、さらに price_usd の値が 100 を超える値に設定されているメッセージ属性またはメッセージ本文プロパティと一致します。

注記

AND ロジックを同じ属性の値に適用することはできません。

OR ロジック

プロパティ名に複数の値を割り当てることで OR ロジックを適用できます。

次のポリシーについて考えます。

{ "customer_interests": ["rugby", "football", "baseball"] }

このポリシー属性は、customer_interests の値が rugbyfootballまたは baseball に設定されているメッセージ属性またはメッセージ本文プロパティと一致します。

OR 演算子

"$or" 演算子を使用してフィルターポリシーを明示的に定義し、ポリシー内の複数の属性間の OR 関係を表すことができます。

Amazon SNS は、ポリシーが以下の条件をすべて満たしている場合にのみ "$or" 関係を認識します。これらの条件がすべて満たされない場合、"$or" はポリシー内の他の文字列と同様に通常の属性名として扱われます。

  • ルールには "$or" フィールド属性が付けられ、その後に配列 (“$or” : [] など) が続きます。

  • "$or" 配列には少なくとも次の 2 つのオブジェクトがあります: "$or": [{}, {}]

  • "$or" 配列内のどのオブジェクトにも、予約キーワードであるフィールド名はありません。

それ以外の場合は、ポリシー内の他の文字列と同様に、"$or" は通常の属性名として扱われます。

数値とプレフィックスは予約キーワードであるため、以下のポリシーは OR 関係として解析されません。

{ "$or": [ {"numeric" : 123}, {"prefix": "abc"} ] }

OR 演算子の例

標準の OR:

{ "source": [ "aws.cloudwatch" ], "$or": [ { "metricName": [ "CPUUtilization" ] }, { "namespace": [ "AWS/EC2" ] } ] }

このポリシーのフィルターロジックは次のとおりです。

"source" && ("metricName" || "namespace")

このポリシー属性は、以下のメッセージ属性セットのいずれとも一致します。

"source": {"Type": "String", "Value": "aws.cloudwatch"}, "metricName": {"Type": "String", "Value": "CPUUtilization"}

または

"source": {"Type": "String", "Value": "aws.cloudwatch"}, "namespace": {"Type": "String", "Value": "AWS/EC2"}

以下のメッセージ本文のいずれとも一致します。

{ "source": "aws.cloudwatch", "metricName": "CPUUtilization" }

または

{ "source": "aws.cloudwatch", "namespace": "AWS/EC2" }

OR 関係を含むポリシー制約

次のポリシーについて考えます。

{ "source": [ "aws.cloudwatch" ], "$or": [ { "metricName": [ "CPUUtilization", "ReadLatency" ] }, { "metricType": [ "MetricType" ] , "$or" : [ { "metricId": [ 1234, 4321 ] }, { "spaceId": [ 1000, 2000, 3000 ] } ] } ] }

このポリシーのロジックは次のように簡略化することもできます。

("source" AND "metricName") OR ("source" AND "metricType" AND "metricId") OR ("source" AND "metricType" AND "spaceId")

OR 関係のあるポリシーの複雑さの計算は、各 OR ステートメントの組み合わせの複雑さの合計として簡略化できます。

組み合わせの合計は次のように計算されます。

(source * metricName) + (source * metricType * metricId) + (source * metricType * spaceId) = (1 * 2) + (1 * 1 * 2) + (1 * 1 * 3) = 7

source には 1 つの値、metricName には 2 つの値、metricType には 1 つの値、metricId には 2 つの値、spaceId には 3 つの値があります。

次のネストされたフィルターポリシーについて考えてみます。

{ "$or": [ { "metricName": [ "CPUUtilization", "ReadLatency" ] }, { "namespace": [ "AWS/EC2", "AWS/ES" ] } ], "detail" : { "scope" : [ "Service" ], "$or": [ { "source": [ "aws.cloudwatch" ] }, { "type": [ "CloudWatch Alarm State Change"] } ] } }

このポリシーのロジックは次のように簡略化できます。

("metricName" AND ("detail"."scope" AND "detail"."source") OR ("metricName" AND ("detail"."scope" AND "detail"."type") OR ("namespace" AND ("detail"."scope" AND "detail"."source") OR ("namespace" AND ("detail"."scope" AND "detail"."type")

組み合わせの合計の計算は、キーのネストレベルを考慮する必要がある点を除いて、ネストされていないポリシーでも同じです。

組み合わせの合計は次のように計算されます。

(2 * 2 * 2) + (2 * 2 * 2) + (2 * 2 * 2) + (2 * 2 * 2) = 32

metricName には 2 つの値、namespace には 2 つの値があります。scope は、1 つの値を持つ 2 レベルのネストされたキー、source は 1 つの値を持つ 2 レベルのネストされたキー、type は 1 つの値を持つ 2 レベルのネストされたキーです。