AWS IAM Policy Conditions Explained: Operators, Keys, Examples & Use Cases

IAM policy conditions in simple terms

A normal IAM statement answers two questions: what action and on what resource. A condition adds a third: under what circumstances.

You are not changing what the permission grants. You are controlling the context in which it applies. The action is the same. The resource is the same. But now the permission only takes effect when specific facts about the request are true: whether the caller used MFA, what IP they called from, which region the API targets, or whether the connection uses TLS.

If a condition is not met, the statement is skipped. An Allow statement with an unmet condition does not allow. A Deny statement with an unmet condition does not deny.

How IAM policy conditions work

A Condition block sits inside a policy statement alongside Effect, Action, and Resource. It contains one or more condition operators (like StringEquals or Bool), each containing one or more condition key-value pairs.

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": {
    "StringEquals": {
      "aws:RequestedRegion": "us-east-1"
    }
  }
}

Four terms to know:

• Condition operator is the comparison type (StringEquals, Bool, IpAddress, etc.)
• Condition key is the variable AWS evaluates from the request (aws:RequestedRegion, aws:SourceIp, etc.)
• Request context is the set of facts AWS collects about the request at evaluation time (who, from where, when, how)
• Policy variable is a dynamic placeholder like ${aws:username} that AWS resolves to the actual value at request time

How AWS evaluates a condition

1. AWS receives the API request and builds the request context (caller identity, IP, region, MFA status, timestamp, etc.).
2. For each policy statement that matches the action and resource, AWS checks the Condition block.
3. Each condition operator compares its condition key against the request context value using the operator’s comparison logic.
4. If the condition key is present and the comparison is true, that condition passes.
5. If the condition key is present and the comparison is false, that condition fails.
6. If the condition key is missing from the request context, the condition fails. The exception is IfExists variants, which treat a missing key as a pass.
7. All conditions in a statement must pass for the statement to apply.

AND vs OR logic

Condition logic follows two rules:

• Multiple values for the same key are OR’d. Any one match is enough. Example: “aws:RequestedRegion”: [“us-east-1”, “eu-west-1”] matches either region.
• Multiple keys or multiple operators are AND’d. All must be true. A statement with both StringEquals on region and Bool on MFA requires both to pass.

{
  "Condition": {
    "StringEquals": {
      "aws:RequestedRegion": ["us-east-1", "us-west-2"],
      "ec2:ResourceTag/Environment": "dev"
    },
    "Bool": {
      "aws:MultiFactorAuthPresent": "true"
    }
  }
}

This means: region is us-east-1 OR us-west-2, AND the instance tag is dev, AND MFA is present. All three lines must be satisfied.

Common condition operators

Every operator also has an IfExists variant (e.g. StringEqualsIfExists, IpAddressIfExists) that only applies the condition when the key exists in the request context.

Common condition keys

Condition keys come in two categories: global keys (prefixed with aws:) that are available for all services, and service-specific keys (prefixed with the service name) that only apply to that service’s API calls.

Global condition keys

S3-specific condition keys

When to use IAM policy conditions

• Require MFA for destructive actions. Deny deleting IAM users, detaching policies, or leaving an organization unless the session used MFA. This protects against compromised passwords that lack the second factor.

• Restrict actions to approved regions. Prevent resource creation outside specific regions for compliance, data residency, or cost control. Often combined with Service Control Policies at the organization level.

• Limit shared-bucket access by prefix. In a shared S3 bucket, give each team or user access only to objects under their own prefix using s3:prefix and policy variables.

• Require HTTPS. Deny S3 or other API requests that do not use TLS, ensuring data in transit is always encrypted.

• Restrict access by IP or VPC endpoint. Limit API access to requests from your corporate network or a specific VPC endpoint, preventing access from unexpected locations.

• Tag-based access control. Use ec2:ResourceTag or s3:ExistingObjectTag conditions to allow actions only on resources tagged with specific values like Environment=dev.

• Add constraints to trust policies for role assumption. Require that only principals from a specific account, with MFA, or from a specific source IP can assume a role.

When not to use IAM policy conditions

• When an SCP is the right tool. If you want to block all users across an entire organization or OU from using a region or service, that is a governance guardrail. Use a Service Control Policy, which applies to every principal in the account regardless of their individual policies.

• When a bucket policy or trust policy is the right location. Conditions on an S3 bucket policy are evaluated at the bucket. Conditions on an IAM role trust policy control who can assume that role. Putting these conditions on a user’s identity policy instead means they can be bypassed if the user has other permissive policies. Choose the policy location that cannot be circumvented.

• When the logic is getting complex enough to be fragile. If you are stacking five conditions with mixed AND/OR logic, you are likely better off restructuring your permissions into simpler, narrower policies. Complex conditions are hard to audit and easy to get wrong.

IAM policy conditions vs resource scoping

• Resource scoping means putting specific ARNs in the Resource field. It is static, simple, and the most readable option. Use it whenever you know exactly which resources the principal needs.
• Conditions evaluate dynamic context at request time. Use them when you need runtime checks that resource ARNs cannot express, like “only if the request comes from this VPC” or “only if the object is tagged production.”

Prefer resource scoping when you can. Add conditions when the restriction depends on context that the Resource field cannot capture. The two are complementary, not interchangeable.

IAM policy conditions vs Service Control Policies

• IAM conditions add requirements to one policy statement. They control when a specific allow or deny applies for whatever principals are subject to that policy.
• SCPs set maximum permission boundaries for an entire AWS account or OU. They apply to every principal in the account (except the management account root user). An SCP deny overrides any IAM allow.

Use conditions for fine-grained, per-principal context checks. Use SCPs for organization-wide guardrails. For region restrictions, SCPs with conditions are the standard pattern: a Deny with StringNotEquals on aws:RequestedRegion applied as an SCP.

IAM policy conditions vs S3 bucket policies

• IAM policy with conditions is attached to the principal (user or role). It travels with the principal and applies to whatever buckets the policy’s Resource field covers.
• S3 bucket policy is attached to the bucket. It controls access to that specific bucket regardless of what IAM policies the caller has.

For bucket-specific rules like “deny all non-HTTPS requests to this bucket” or “restrict access to requests from this VPC endpoint,” a bucket policy is the right location. The restriction lives with the resource and cannot be overridden by a permissive IAM policy on the caller. Use IAM policy conditions when the restriction should follow the principal, not the bucket.

Examples

Require MFA for sensitive actions

Deny destructive IAM and billing actions when MFA is not present. This pattern uses a Deny statement with BoolIfExists so the deny fires both when MFA is explicitly false and when the key is absent (as happens with long-lived access keys).

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyDestructiveWithoutMFA",
      "Effect": "Deny",
      "Action": [
        "iam:DeleteUser",
        "iam:DeleteRole",
        "iam:AttachRolePolicy",
        "iam:DetachRolePolicy",
        "organizations:LeaveOrganization"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "false"
        }
      }
    }
  ]
}

Restrict actions to approved regions

Deny any API call targeting a region outside your approved list. This is most effective as an SCP applied at the organization or OU level.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideApprovedRegions",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "us-east-1",
            "us-west-2",
            "eu-west-1"
          ]
        }
      }
    }
  ]
}

Any API call targeting a region not in the list is denied. See Restricting Resource Locations in AWS for the full pattern including global service exemptions.

Restrict S3 access to a prefix

Allow a user to list and read/write only objects under their own prefix in a shared bucket.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowListOwnPrefix",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::shared-uploads",
      "Condition": {
        "StringLike": {
          "s3:prefix": "${aws:username}/*"
        }
      }
    },
    {
      "Sid": "AllowReadWriteOwnPrefix",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::shared-uploads/${aws:username}/*"
    }
  ]
}

The policy variable ${aws:username} resolves to the caller’s IAM username at request time. Each user gets access only to their own prefix without hardcoding names.

Require HTTPS for S3

Deny any S3 request that does not use TLS. This belongs on the bucket as a bucket policy, not on a user’s IAM policy, so the restriction applies to every caller.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyInsecureTransport",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": [
        "arn:aws:s3:::sensitive-data-bucket",
        "arn:aws:s3:::sensitive-data-bucket/*"
      ],
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      }
    }
  ]
}

Restrict access by VPC endpoint or source IP

Deny S3 access unless the request comes through a specific VPC endpoint:

{
  "Sid": "DenyOutsideVpce",
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": [
    "arn:aws:s3:::internal-data",
    "arn:aws:s3:::internal-data/*"
  ],
  "Condition": {
    "StringNotEquals": {
      "aws:SourceVpce": "vpce-0abc1234def567890"
    }
  }
}

Use conditions in a trust policy

Conditions in a role trust policy control who can assume the role. This example requires MFA and restricts assumption to a specific account:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowCrossAccountWithMFA",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    }
  ]
}

In a trust policy, the principal has already been identified by the Principal field. The condition adds an extra gate. Here, the assuming user’s session must include MFA. Because sts:AssumeRole is called from an existing session (not from bare access keys), aws:MultiFactorAuthPresent is present in the request context, so Bool is appropriate.

How to test and troubleshoot condition-based policies

• Use the IAM Policy Simulator. The simulator lets you test API calls against your policies with specific context values (region, IP, MFA status). It shows which statements matched, which conditions passed or failed, and the final allow/deny decision. Always simulate before deploying condition-heavy policies.

• Read the AccessDenied message carefully. When a request is denied, AWS sometimes indicates which policy or condition caused the denial. Cross-reference the denied action with your condition keys. If you are debugging an unexpected denial, check whether the condition key is actually present in the request context for that call type.

• Verify your assumptions about the request context. Not every key is present in every request. aws:MultiFactorAuthPresent is absent for access-key calls. aws:SourceIp is empty for VPC endpoint traffic. aws:SourceVpce is only present when the request actually traversed a VPC endpoint. If your condition depends on a key, confirm that it is populated for the specific call pattern you are testing.

• Use the AWS CLI to test specific calls. Run the actual API call with the CLI using a test identity and check whether it succeeds or fails. Combine this with CloudTrail to see the full request context that AWS evaluated.

• Check CloudTrail for evaluation details. CloudTrail logs show the request parameters, the calling identity, and the source IP. Comparing a CloudTrail event to your condition helps you identify exactly which condition key value did not match.