iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
AWS IAM does not remove network controls. It changes what a network boundary has to prove. In AWS’s data-perimeter model, access inside the perimeter requires three things at once: a trusted identity, a trusted resource, and an expected network. The network is one of those three conditions. Meeting all of them is necessary for access, but it is not sufficient to grant access.
What an AWS data perimeter is
An AWS data perimeter is a set of organization-wide guardrails around three things: the identities you trust, the resources you trust, and the networks you expect requests to come from. AWS describes these controls as coarse-grained. They do not replace fine-grained access controls. AWS’s IAM documentation page on data perimeters says it directly: “These organization-wide permissions guardrails do not replace your existing fine-grained access controls.”
The accurate reading of “replaces” is therefore a change of emphasis. Identity and resource context do more of the security work than they did when location was the main signal. Network controls remain one of three dimensions rather than disappearing.
Free tools Windows power users keep installed
One-click scans. No signup required.
The three conditions
AWS’s perimeter overview whitepaper states the model as a formula:
#1 Best Overall
Access in the Perimeter⇒(Trusted Identity)∧(Trusted Resource)∧(Expected Network)
- Trusted identity: the calling principal is one your organization has decided to trust. AWS’s examples express this with organization identifiers such as
aws:PrincipalOrgID. - Trusted resource: the resource being accessed belongs to a trusted organization. The SCP examples use
aws:ResourceOrgIDfor this check. - Expected network: the request arrives from a network you planned for, such as an IP range, a VPC, or a VPC endpoint.
Which policy type enforces which part
Four policy types carry the perimeter. Each one sits at a different enforcement point, so each covers a different part of a request.
| Control | Enforced at | What it constrains | Example keys in AWS guidance | Specific limit |
|---|---|---|---|---|
| Service control policy (SCP) | Organization; applies to principals in member accounts | Which resources identities may access, and from which networks they may send requests | aws:ResourceOrgID, aws:SourceIp, aws:SourceVpc, aws:ViaAWSService |
Organization-wide, so an overly broad denial reaches every covered account |
| Resource control policy (RCP) | Organization; attached on the resource side | Which principals and networks may access covered resources | aws:PrincipalOrgID, aws:SourceVpc |
Covers supported resources only; service principals and service-mediated requests need considered exceptions |
| VPC endpoint policy | The individual VPC endpoint | Principals and resources reachable through that endpoint | Not stated in AWS’s perimeter guidance | Does not replace policies attached to identities or destination resources |
| Resource-based policy | The resource itself | Direct permissions on that resource | Not stated in AWS’s perimeter guidance | Used to apply guardrails where RCP support is unavailable |
None of the four grants an action by itself. A guardrail narrows what is possible, and an identity or resource policy still has to allow the request.
Network conditions remain part of the model
The expected-network condition is written with six condition keys. Three describe the path a request took:
aws:SourceIp: the IP address the request came from.aws:SourceVpc: the VPC the request came from.aws:SourceVpce: the VPC endpoint the request used.
The other three identify who owns the endpoint:
aws:VpceAccount: the account that owns the endpoint.aws:VpceOrgPaths: the organization paths of the endpoint owner.aws:VpceOrgID: the organization that owns the endpoint.
Choosing between endpoint-owner keys and path keys
AWS describes the endpoint-owner keys as a way to scale as endpoint usage grows. It also cautions that they should be used only when every service you restrict supports them. If your perimeter has to cover services with broader or mixed support, AWS suggests using aws:SourceVpc and aws:SourceVpce instead. Service support for these keys is not fixed, so check the current list in AWS’s documentation before copying a condition into a production policy.
Service-mediated access is the exception to plan for
AWS services sometimes act on your resources for a principal, through service principals or forward access sessions. A perimeter written only as “deny requests from outside my network” also blocks these requests, which can break a valid workflow. Two keys handle these paths:
aws:ViaAWSService: identifies requests that an AWS service makes on a principal’s behalf.aws:PrincipalIsAWSService: identifies requests whose principal is an AWS service.
Build each exception from the access you intend to allow, not from a broad allowance. Every exception should be explicit, reviewed, and checked against the service-support caveats above.
Quick wins for a faster PC:
Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →How to evaluate a perimeter design
Compare candidate designs on five axes:
- Enforcement point: is the control on the principal (SCP), the resource (RCP or resource-based policy), or the endpoint (endpoint policy)?
- Condition: which of the three conditions, trusted identity, trusted resource, or expected network, does it enforce?
- Key and service support: do the keys you chose work for every service the perimeter must cover?
- Legitimate exceptions: which AWS service or partner access paths need an explicit exception, and is each one reviewed?
- Review: which tool or rule will show policy drift over time?
When a legitimate request is denied
Work back from the three conditions and identify the one the request fails.
Best Value
- An AWS service makes the call for a principal. Check whether an SCP or RCP condition denies it, and whether an explicit
aws:ViaAWSServiceoraws:PrincipalIsAWSServiceexception covers that path. - The request goes through a VPC endpoint. Check the endpoint policy. The endpoint adds a boundary, so an allow in the identity policy does not by itself let the request through.
- The request comes from a network you expected, but is still denied. Confirm that the key you used (
aws:SourceIp,aws:SourceVpc, oraws:SourceVpce) matches the path the traffic actually takes. Then confirm that the identity or resource policy allows the action.
Rolling out and monitoring a perimeter
Treat the perimeter as part of your security risk-management program rather than a one-time configuration. In practice:
Quick Recap
- Write down the intended access patterns and the threats each control addresses before writing policy. AWS recommends starting here, because legitimate traffic defines the exceptions.
- Use IAM Access Analyzer to inspect resource-based policies and to evaluate the guardrails you plan to apply.
- Review SCPs, IAM policies, and VPC endpoint policies together, since a guardrail in one place can interact with an allow in another.
- Monitor with AWS Config. AWS Prescriptive Guidance names the AWS Config rule
SERVICE_VPC_ENDPOINT_ENABLEDin its monitoring recommendations. Confirm the rule’s applicability and configuration in the AWS Config documentation before relying on it in a specific environment. - Keep reviewing policy configuration after rollout, because services, condition-key support, and access patterns change.
What the evidence does and does not establish
- None of the AWS sources cited here includes a statistic on how much a data perimeter reduces breaches, misconfigurations, or cost, so no such figure should be attributed to AWS.
- These are implementation guidance documents. They establish what the controls are and how they interact. They do not show that a particular deployment will produce a particular security result.
- The sources are AWS documentation rather than named-author commentary, so the quotations in this article are attributed to AWS documentation, not to individuals.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
