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 の値が rugby、football、または 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 レベルのネストされたキーです。