IAM Condition Policies: The Most Underused Tool

Condition keys narrow IAM policies dramatically. The conditions that produce the highest security gain.

aws:SourceIp

IAM condition policies are the layer of IAM that lets the team express "this action is allowed only when these conditions are met". Conditions add context-aware enforcement on top of basic action permissions. Disciplined use of conditions produces tight, auditable IAM that catches accidents and prevents abuse.

What aws:SourceIp provides:

• Limit access to specific IP ranges.: The condition restricts an action to requests from specific source IPs. Office IP ranges, VPN endpoints, partner network blocks. Requests from other IPs are denied even if the principal has the action permission.
• Effective for office-only roles.: Roles that should only be used from corporate networks benefit. Even if a credential leaks, an attacker outside the allowed IP range cannot use it. The defense-in-depth value is real.
• Combined with VPN, satisfies most 'private access' requirements.: The combination of IP restriction plus VPN access creates a "must be on the network" requirement. Many compliance frameworks accept this as private access; the auditor sees the technical enforcement.
• Watch for NAT and proxy gotchas.: Source IP visibility depends on the network path. Behind NAT, the source IP is the NAT gateway's IP. Behind proxies, it's the proxy's. The condition must use the IP that AWS actually sees, not the original client IP.
• Plan for IP changes.: When the office IP range changes (new ISP, new office, IPv6 rollout), policies must be updated. The IP list is documented; updates follow a defined process. Drift is a real failure mode.

aws:SourceIp is one of the simplest and highest-leverage conditions. It prevents whole classes of credential abuse.

aws:SourceVpc

aws:SourceVpc and the related aws:SourceVpce condition restrict actions to requests originating from specific VPCs or VPC endpoints. The conditions are particularly valuable for S3 and other resources where access patterns should be constrained to known network paths.

• Limit access to specific VPCs.: The condition allows access only when the request comes through a specific VPC. Cross-account access via misrouted credentials is blocked; the condition enforces the network boundary.
• Catches cross-account access through unintended paths.: Without the condition, a role assumed across account boundaries can access resources from any source. With the condition, the access is constrained to specific VPCs; unintended paths are blocked.
• Especially useful for S3 buckets.: S3 buckets that should only be accessed from specific VPCs benefit greatly. Bucket policies with aws:SourceVpc conditions prevent public-internet access even if the bucket policy itself is permissive.
• Combine with VPC endpoints.: aws:SourceVpce restricts to specific VPC endpoints. The combination of VPC endpoints (private connectivity) and the condition (enforce-only-via-endpoint) produces a tight private access model.
• Watch for legitimate cross-VPC access.: Legitimate cross-VPC patterns (Transit Gateway, peering) need the policy to include their source VPCs. The condition is constructive enforcement, not blanket denial.

aws:SourceVpc is the right tool when network-level enforcement of access matters. It catches misrouted access that pure IAM action permissions would not.

aws:MultiFactorAuthPresent

The MFA condition requires that the request was made with multi-factor authentication. The condition adds the strongest possible authentication assurance to actions that justify it.

• Require MFA for sensitive actions.: Administrative actions, financial actions, and other high-stakes operations should require MFA. The condition enforces it; actions attempted without MFA are denied.
• Standard for admin roles.: Administrative roles uniformly require MFA. The condition is part of the standard role configuration; new admin roles inherit it; deviations require justification.
• MFA condition is one of the highest-leverage policy additions.: The cost of adding the condition is small (a few lines in a policy); the value is large (compromised credentials cannot perform sensitive actions without the second factor). The cost-benefit strongly favors the condition.
• Compatible with federated identity.: When users authenticate via SSO (AWS SSO, Okta, similar), MFA at the identity provider produces the MFA-present claim. The condition works across federated and IAM-native authentication paths.
• Verify MFA enforcement actually works.: Periodically test the condition: try a sensitive action without MFA; confirm it is denied. The verification catches misconfiguration before it matters.

IAM condition policies are where IAM moves from action-based to context-based enforcement. Nova AI Ops integrates with IAM data, surfaces actions that should have conditions but do not, and produces the audit-ready inventory that compliance discussions reference.