Amazon Web Services (AWS) is a foundational platform for cloud infrastructure, hosting critical applications, data, and services. Because these environments often contain sensitive resources, securing access is crucial.
To reduce the risk of unauthorized access, data breaches, or service disruption, restrict access to specific IP addresses using Conditional Access policies in Microsoft Entra ID.
This adds a crucial layer of protection by limiting where access can originate.
Why you should restrict AWS access by IP address
The key benefits of restricting AWS access by IP address include:
- Even if credentials are compromised, attackers cannot access AWS from outside approved networks.
- Your sensitive data and workloads are protected, and access is limited to trusted environments only.
- Administrative access is limited to known, controlled locations, reducing the risk of account takeover or privilege abuse.
- Foundational control that can be layered with multi-factor authentication and Identity and Access Management policies.
- Helps meet compliance and regulatory requirements and strengthens overall security posture.
How to restrict AWS access to specific IP addresses using Conditional Access (step-by-step)
When users authenticate to AWS through IAM Identity Center with Entra ID as the identity provider, Conditional Access policies are evaluated at sign-in time, making it possible to block access from any IP not on your approved list before a SAML assertion is ever issued to AWS.
The approach uses two components working together:
Named Locations: A saved list of trusted IP addresses or CIDR ranges defined in Entra ID.
Conditional Access policy: A policy that blocks AWS sign-ins originating from any IP not on the trusted list.
NOTE: This configuration requires AWS IAM Identity Center to be integrated with Microsoft Entra ID via SAML SSO and SCIM provisioning. If that integration is not yet in place, complete it first before proceeding. Refer to the AWS IAM Identity Center SSO KB article for setup instructions.
Prerequisites
Before proceeding, confirm the following are in place:
- Microsoft Entra ID P1 or P2 license — required for Conditional Access.
- Conditional Access Administrator role or higher in Microsoft Entra ID.
- AWS IAM Identity Center enterprise app registered in your Entra ID tenant with SAML SSO configured and SCIM provisioning active.
- Security Defaults disabled — Security Defaults and Conditional Access cannot run simultaneously.
- Known static IP address(es) — the public IP address or CIDR range of each approved location (office, VPN egress, etc.).
- Break-glass admin account — must be excluded from this policy to prevent administrative lockout.
IMPORTANT: If your approved IP address is dynamic, this approach will not work reliably. You must use a static IP or a VPN with a fixed egress IP before implementing IP-based Conditional Access.
Step 1: Create a Named Location for your trusted IP(s)
A Named Location defines the trusted IP addresses that Entra ID will reference as a condition in the policy.
- Sign in to the Microsoft Entra admin center at entra.microsoft.com.
- Navigate to Protection > Conditional Access > Named locations.
- Select + IP ranges location.
- Name the location — for example: Trusted - Corporate Office
- Check the Mark as trusted location checkbox.
- Click + and enter your approved IP address or CIDR range.
- Examples:
- Single IP address: 203.0.113.10/32
- IP range (CIDR): 203.0.113.0/24
- Multiple sites: Create a separate Named Location for each site or VPN egress IP, then reference all of them in the policy.
- Examples:
- Click Create.
Step 2: Create the Conditional Access policy
Create a policy that blocks AWS IAM Identity Center access from any location not on your trusted list.
- In the Entra admin center, navigate to Protection > Conditional Access > Policies.
- Select + New policy.
- Name the policy — for example: Block AWS - Outside Trusted IPs
Assignments: Users
- Under Assignments > Users, select All users.
- Under Exclude, add your break-glass admin account and any automation or service accounts that authenticate from dynamic IPs.
NOTE: AWS automation workflows and CI/CD pipelines that authenticate through IAM Identity Center will also be subject to this policy. Identify and exclude any service principals or accounts used for programmatic access before enabling enforcement.
Assignments: Target resources
- Under Target Resources, select Cloud apps > Select apps.
- Search for and select AWS IAM Identity Center.
Conditions: Locations
- Under Conditions > Locations, set Configure to Yes.
- Under Include, select Any location.
- Under Exclude, select Selected locations, then choose your Named Location from Step 1.
TIP: This configuration reads: apply this policy to sign-ins from any location, except the trusted named location. Any AWS sign-in originating outside the trusted IP will be blocked before a SAML assertion is issued to IAM Identity Center.
Access controls: Grant
- Under Access Controls > Grant, select Block access.
- Click Select to confirm.
Enable policy
- Set Enable policy to Report-only.
- Click Create.
IMPORTANT: Do not set this policy to On immediately. A block policy applied to All users that is misconfigured will block all users from authenticating to AWS instantly. Validate in Report-only mode first.
Step 3: Validate the policy
Before enabling enforcement, confirm the policy is evaluating correctly.
- In the Entra admin center, navigate to Identity > Monitoring & health > Sign-in logs.
- Filter by the AWS IAM Identity Center application.
- Open a sign-in from a user on your trusted IP and confirm the Conditional Access tab shows Would succeed.
- If available, review a sign-in from an untrusted IP and confirm it shows Would fail with the location condition as the reason.
- Pay close attention to any accounts used for automated AWS workflows. Confirm they are either excluded or authenticating from a trusted IP.
TIP: Use the What If tool under Protection > Conditional Access to simulate how a specific user or service account signing in from a specific IP would be evaluated without waiting for a real sign-in event.
Step 4: Enable the policy
- In the Entra admin center, navigate to Protection > Conditional Access > Policies.
- Select the policy created in Step 2.
- Change Enable policy from Report-only to On.
- Click Save.
From this point forward, any AWS IAM Identity Center sign-in attempt from an IP address not included in your Named Location will be blocked. Entra ID will not issue a SAML assertion to IAM Identity Center, and the user will not be able to access the AWS access portal.
NOTE: Active AWS console sessions at the time of policy enablement will not be immediately terminated. The block takes effect on the next sign-in or token refresh. AWS session duration is controlled by IAM Identity Center session settings and typically expires within 1–12 hours.
Summary
The following summarizes the full configuration process:
Prerequisites
Confirm license, IAM Identity Center SSO configured, Security Defaults disabled, static IP(s) identified.
Step 1
Create a Named Location with your trusted IP address(es).
Step 2
Create a CA policy targeting AWS IAM Identity Center, excluding the Named Location, with Block access.
Step 3
Validate in Report-only mode using sign-in logs and the What If tool.
Step 4
Switch Enable policy to On.
FAQs
Can AWS restrict access by IP address natively?
Yes, AWS supports IP-based restrictions through IAM policies and security controls. However, many organizations also enforce access restrictions using an identity provider with Conditional Access for centralized policy management.
What happens if a user tries to access AWS from an unapproved IP address?
Access will be denied, preventing login or API interaction unless the request originates from an approved IP address.
Is restricting AWS access by IP enough?
While it significantly reduces risk, it should be combined with additional controls such as MFA, least privilege IAM policies, and Zero Trust enforcement.
Can attackers bypass IP-based restrictions?
Attackers may attempt to use compromised VPNs or proxy services. That’s why IP restrictions should be layered with identity verification, device posture checks, and continuous monitoring.


