Back to all operators

StringNotEqualsIgnoreCaseIfExists

StringNotEqualsIgnoreCaseIfExists

compares a string in a request to a list of strings in your policy. The comparison is case insensitive.

To match a request, the context key can be absent, but if present it must NOT match any of the strings in your policy.

You can use policy variables in the value of this operator.

So you know

StringNotEqualsIgnoreCaseIfExists behaves exactly the same as StringNotEqualsIgnoreCase. "Negative" operators such as StringNotEqualsIgnoreCase already match requests when the key is not present, so the IfExists suffix has no effect. There is no harm in adding IfExists — it arguably makes the intent clearer.

StringNotEqualsIgnoreCaseIfExists in an Allow Statement

Simulate in IAM Simulate
Policy ConditionRequest ContextResult
"StringNotEqualsIgnoreCaseIfExists": {
"aws:RequestTag/DataClass": [
"public",
"internal"
]
}
aws:RequestTag/DataClass: null✓ Allowed Assuming no explicit Deny elsewhere
"StringNotEqualsIgnoreCaseIfExists": {
"aws:RequestTag/DataClass": [
"public",
"internal"
]
}
aws:RequestTag/DataClass: private✓ Allowed Assuming no explicit Deny elsewhere
"StringNotEqualsIgnoreCaseIfExists": {
"aws:RequestTag/DataClass": [
"public",
"internal"
]
}
aws:RequestTag/DataClass: PUBLIC− Not Allowed Statement does not apply

StringNotEqualsIgnoreCaseIfExists in a Deny Statement

Simulate in IAM Simulate
Policy ConditionRequest ContextResult
"StringNotEqualsIgnoreCaseIfExists": {
"aws:RequestTag/DataClass": [
"public",
"internal"
]
}
aws:RequestTag/DataClass: null✕ Denied
"StringNotEqualsIgnoreCaseIfExists": {
"aws:RequestTag/DataClass": [
"public",
"internal"
]
}
aws:RequestTag/DataClass: private✕ Denied
"StringNotEqualsIgnoreCaseIfExists": {
"aws:RequestTag/DataClass": [
"public",
"internal"
]
}
aws:RequestTag/DataClass: PUBLIC− Not Denied May be allowed by another statement