Wednesday, October 7, 2026

AWS Identity Store Network Access Controls: Which API Requests Can Be Restricted?

AWS announced network access controls for IAM Identity Center’s Identity Store.

The available restrictions differ between the Identity Store API and the SCIM API; this article separates those options from the defaults, exemptions and deployment results the announcement does not verify.

Data Center News & Trends

What did AWS announce?

AWS says IAM Identity Center now supports network access controls for Identity Store, which stores users and groups. The announcement feed lists October 5, 2026, as its publication date; it does not establish a separate rollout date.

The controls concern where requests to two interfaces originate. AWS describes custom applications and user-provisioning workflows using the Identity Store API to manage or look up users and groups, while external identity providers use the SCIM API to synchronize them.

AWS — AWS IAM Identity Center now supports network access controls for Identity Store

Which restrictions apply to each API?

The VPC-based options AWS describes are for the Identity Store API. IP-range restrictions can be applied to either API, and the two APIs can have different restrictions in the same configuration.

Identity Store API

Network-origin restrictions AWS describes
Require requests through allowed VPC endpoints in the account or organization, or from specified source VPCs; allow requests only from specified IP ranges

SCIM API

Network-origin restrictions AWS describes
Allow requests only from specified IP ranges

For example, AWS describes restricting Identity Store API requests to VPC endpoints while allowing SCIM requests from an external identity provider’s published IP ranges. That illustrates a possible configuration, not a required one. The announcement does not describe the VPC endpoint or source-VPC options as SCIM API restrictions.

Are the controls already on for every request?

No. AWS says the controls are optional and off by default. Requests that AWS services make on a user’s behalf are exempt, so the announced restrictions should not be read as applying to every request associated with an Identity Store workflow.

AWS says the controls are configured through the Identity Store API using AWS SDKs or the AWS CLI and are available in AWS Regions where IAM Identity Center is offered. Availability does not establish that a particular account has enabled them.

What should a team check before drawing a deployment conclusion?

The announcement establishes configuration options, not a tested outcome for a particular deployment. It does not verify that every unwanted request would be blocked or that existing applications and synchronization workflows would continue without disruption.

The useful next question is where each request actually originates and how it reaches its API. Consider Identity Store API applications and provisioning separately from SCIM synchronization, then compare each path with the restriction selected for that API.

Include whether the control is enabled and whether an AWS service is making a request on the user’s behalf. Only that environment-specific assessment can support a conclusion about which requests the configuration would restrict and which workflows might be affected.

Sources

No comments:

Post a Comment