Full Report
AWS has released three new IAM condition keys for VPC endpoints to strictly limit access by specific accounts, organizational units, or AWS Organizations. Learn how these keys help you build scalable security perimeters and reduce manual policy maintenance.Key takeawaysSimplify cloud perimeters with AWS: AWS IAM condition keys let you restrict access by account, organization, or OU without managing manual VPC lists.Scale guardrails: Combined with RCPs, these keys enable consistent, org-wide perimeter enforcement across accounts.Apply carefully: Support is limited to select services, so test thoroughly and include exceptions for AWS-managed access.AWS announced recently the release of three identity and access management (IAM) condition keys for virtual private cloud (VPC) endpoints. These keys make it much easier to establish strong, scalable perimeters around your resources. With them, you can restrict access so that only requests coming from VPC endpoints in specific AWS accounts, organizational units (OU) paths, or AWS Organizations are allowed.In this blog, we’ll explain how these keys can help you apply permissions perimeters at scale and reduce your attack surface without drowning in manual policy management. Why perimeters around data matterIn traditional on-premises environments, the network perimeter was the main defense. In the cloud, that boundary has shifted, and identity has become the new perimeter. For sensitive data stored in assets such as S3 buckets, databases, and secrets, strong perimeters are essential. Often when misconfigured access causes breaches, it’s not because the hacked resources lack IAM, but because policies are too permissive.Mastering identity and network perimeters in AWS can drastically reduce exposure. The trick is applying them consistently, at scale.Guardrails in AWSAWS provides multiple layers of controls, such as:Resource-based policies: Controls enforced directly at the resource (e.g., bucket policies)Service control policies (SCPs): Organizational guardrails for what accounts or OUs can doResource control policies (RCPs): Fine-grained policies across multiple accountsPermission boundary: Permissions guardrails to limit specific IAM entitiesTogether, these guardrails help you enforce least privilege while keeping control centralized.VPC endpoints as a building blockA VPC endpoint lets resources within your VPC reach AWS services directly, without traversing the public internet. On top of other benefits of this configuration, requests through endpoints carry condition keys such as aws:SourceVpc, which help identify the source of the request. This allows you to create policies that enforce the simple yet effective rule of: “Only allow this bucket to be accessed from this VPC.”For example, you can use a Condition element with this key to create exceptions for requests coming from certain VPCs. The following policy taken from the AWS security blog illustrates this. (We have bolded part of the code for emphasis.) Using a policy like this one helps ensure requests flow through known, private channels. But until now, scaling these controls across accounts and organizations was a tedious manual process.The challenge of scaleSo let’s say you don’t want to just limit access from a single VPC, but from all VPCs of a certain AWS account, or from several accounts, or even from your entire AWS organization. If you wanted to do this, you would have had to:Manually list every VPC ID in the relevant accounts.Update the list whenever VPCs were added or removed.Manage separate policies per account.This doesn’t scale. It’s error-prone, brittle, and a nightmare to maintain across dozens of accounts.Condition keysAWS has now introduced three global condition keys to simplify this:aws:VpceAccount: The AWS account that owns the VPC endpointaws:VpceOrgID: The AWS Organizations ID of the endpoint’s owning accountaws:VpceOrgPaths: The OU path(s) that the endpoint’s account belongs toWith these, you can create simple conditions that scale naturally.Let’s explore another example taken from the AWS security blog. (Again, we have bolded part of the policy for emphasis.) The section in bold shows an exception for: Requests coming from VPC endpoints within the customer’s organization, using the aws:VpceOrgID condition keyRequests coming from VPC endpoints in allowed third party accounts, using the aws:VpceAccount condition keyAWS services using specific service roles to access your resources, with the aws:PrincipalTag/network-perimeter-exception set to trueIf you wish to further generalize the use of the aws:VpceAccount condition key, you can use it with this syntax …"aws:VpceAccount": "${aws:ResourceAccount}"… which matches the account ID of the VPC endpoint with the account ID of the resource being accessed (as specified here) - if you want for the policy to only allow same-account access.And as exemplified here, you can use the aws:VpceOrgPaths condition key to create this exception for VPC endpoints in accounts that belong in a certain OU path within the organization. Scaling with RCPsBy using these keys inside resource control policies, you can enforce guardrails across dozens or hundreds of accounts without writing separate policies for each one.For example:Require all S3 buckets in an OU to only accept traffic from VPC endpoints owned by accounts in that OU.Block endpoints in “sandbox” OUs from accessing production data.This moves perimeter enforcement from a manual, bucket-by-bucket exercise into a scalable org-wide control.Testing and caveatsRemember that support coverage for these condition keys is only for certain services at launch, including S3, DynamoDB, Key Management Service, and Security Token Service. Check the AWS documentation for the latest availability.As always, use caution when applying guardrails, especially ones that apply across entire accounts such as resource control policies. Note for example that some AWS-managed services such as CloudTrail and Config may need access to your resources. So, as we’ve previously discussed on our blog and also as you may note in the example policies AWS shared on its blog, it’s wise to understand condition keys such as aws:PrincipalIsAWSService and aws:ViaAWSService to create exceptions for those as well. And of course, before you move anything to a higher environment, such as production, always test thoroughly and rigorously in a non-production environment, and make sure no legitimate business functionality is being compromised due to the guardrails. ConclusionWith aws:VpceAccount, aws:VpceOrgID, and aws:VpceOrgPaths keys, AWS has taken a big step toward elegant, scalable perimeters around cloud resources. Instead of brittle, manually maintained lists of VPC IDs, you can now express intent directly: “only from this account,” “only from this org,” or “only from these OUs.”Combined with RCPs, this gives security teams powerful levers to enforce least privilege across fleets of accounts. The key is to test carefully, account for AWS service access, and roll out the condition keys incrementally. Done right, these condition keys make identity truly the perimeter — and make that perimeter enforceable at scale.If you want to learn more about this particular feature, you can get more details in the AWS documentation “AWS global condition context keys” and in the AWS blog “Use scalable controls to help prevent access from unexpected networks.”If you have any specific questions about this AWS feature or about our cloud security solution Tenable Cloud Security, you’re welcome to reach out.
Analysis Summary
# Best Practices: Scaling VPC Endpoint Access Perimeters Using IAM Condition Keys
## Overview
These practices focus on leveraging the new AWS IAM global condition keys (`aws:VpceAccount`, `aws:VpceOrgID`, `aws:VpceOrgPaths`) to establish robust, scalable, and identity-centric security perimeters for resources accessed via VPC endpoints, moving away from brittle, manually managed network lists.
## Key Recommendations
### Immediate Actions
1. **Audit Existing Policies:** Identify resource policies (e.g., S3 bucket policies, DynamoDB policies) that currently rely on enumerating specific VPC IDs (`aws:SourceVpc`) and prioritize migrating them to use the new organizational context keys where applicable.
2. **Test New Keys in Non-Production:** Immediately begin testing the new condition keys (`aws:VpceAccount`, `aws:VpceOrgID`, `aws:VpceOrgPaths`) in development or staging environments to validate intended access restrictions and identify operational dependencies.
3. **Identify AWS Service Exceptions:** Catalog all AWS-managed services (e.g., CloudTrail, Config) that require access to sensitive resources and prepare explicit exceptions using keys like `aws:PrincipalIsAWSService` or `aws:ViaAWSService` within new restrictive policies.
### Short-term Improvements (1-3 months)
1. **Implement Account-Level Restriction:** For highly sensitive data, update resource policies to enforce access only from VPC endpoints originating from known, defined AWS accounts using the `aws:VpceAccount` key.
2. **Enforce Same-Account Access (When Applicable):** Where required, use the syntax `"aws:VpceAccount": "${aws:ResourceAccount}"` in policies to ensure VPC endpoint traffic that accesses a resource originates from the same AWS account hosting the resource.
3. **Deploy OU Path Guardrails:** Utilize the `aws:VpceOrgPaths` key within Resource Control Policies (RCPs) to apply broad perimeter controls, ensuring that resources in a production OU are only accessible via VPC endpoints belonging to accounts within the designated production OU paths (e.g., blocking access from "Sandbox" OUs).
### Long-term Strategy (3+ months)
1. **Centralize Perimeter Enforcement with RCPs:** Integrate the new VPC endpoint condition keys into organizational-level guardrails, specifically Resource Control Policies (RCPs), to consistently enforce perimeter access rules across the entire AWS Organization without per-account maintenance.
2. **Deprecate Manual VPC Lists:** Systematically phase out resource policies that depend on maintaining long, manual lists of VPC IDs, replacing them with organizational or account-based conditions for cleaner, more resilient controls.
3. **Establish Organizational Exception Framework:** Formalize a process for granting exceptions to these strict perimeters, documenting and controlling the use of principal tags (e.g., `aws:PrincipalTag/network-perimeter-exception`) for necessary services or vetted third-party access.
## Implementation Guidance
### For Small Organizations
* Focus on implementing the `aws:VpceAccount` key in resource policies to explicitly define which accounts can access protected resources, as organizational structuring may be less complex.
* Use these keys within standard IAM/resource policies before moving to organization-wide RCPs, focusing on the most critical data stores first.
### For Medium Organizations
* Begin leveraging AWS Organizations structure by implementing controls using `aws:VpceOrgID` to apply consistent rules across development, staging, and production accounts grouped under specific OUs.
* Use RCPs to mandate that all accounts must adhere to these VPC endpoint conditions for accessing key service APIs.
### For Large Enterprises
* **Mandate RCP Usage:** Enforce these perimeter controls primarily through SCPs (for broad limitations) and RCPs (for specific resource access restrictions) layered across the organization hierarchy.
* **Tagging Integration:** Proactively use resource/principal tagging in conjunction with `aws:VpceAccount` and `aws:VpceOrgPaths` to manage complex exception scenarios involving numerous business units or shared services.
* **Organizational Segmentation:** Use `aws:VpceOrgPaths` to create hard boundaries: for example, explicitly deny VPC endpoint access to Production data from any VPC endpoint owning account whose path is under the `/Development/` or `/Sandbox/` OU structures.
## Configuration Examples
| Condition Key | Use Case | Policy Snippet Logic |
| :--- | :--- | :--- |
| `aws:VpceAccount` | Allow access only from VPC endpoints owned by a specific list of accounts. | `"aws:VpceAccount": [ "111122223333", "444455556666" ]` |
| `aws:VpceOrgID` | Allow access only from VPC endpoints belonging to the primary AWS Organization. | `"aws:VpceOrgID": [ "${aws:PrincipalOrgID}" ]` (If used with `aws:PrincipalOrgID` for verification) OR specify the organization ID directly. |
| `aws:VpceOrgPaths` | Restrict access to production resources only from VPC endpoints whose owning accounts reside in the `/Prod/` OU path. | `"aws:VpceOrgPaths": [ "/company-root/production/*" ]` |
| Combined (Same-Account) | Allow access only if the VPC endpoint is in the same account as the resource being accessed. | `"aws:VpceAccount": "${aws:ResourceAccount}"` |
## Compliance Alignment
* **NIST SP 800-53 (AC - Access Control):** Directly supports requirements for boundary protection and least privilege by restricting network access contextually based on trusted organizational location.
* **ISO 27001/27002 (A.9 Access Control):** Enhances controls related to logical access by reinforcing access based on originating control points (VPC endpoints linked to verified accounts/OUs).
* **CIS Benchmarks (General):** Aligns with the principle of minimizing the attack surface by ensuring data access channels are explicitly defined and limited (Identity as the Perimeter).
## Common Pitfalls to Avoid
1. **Ignoring AWS Service Access:** Failing to include explicit exceptions for AWS-managed services (like CloudTrail, Config, or other required cross-account roles) before deploying stringent VPC endpoint controls. This can break essential auditing and operational functions.
2. **Insufficient Testing:** Rolling out organization-wide controls (`aws:VpceOrgPaths` via RCPs) directly to production without rigorous testing in lower environments, leading to the compromise of legitimate business functionality.
3. **Over-reliance on Single Key:** Assuming one key is sufficient; effective security requires combining these keys with other context (e.g., IAM Principal context, resource tags) for comprehensive enforcement.
4. **Assuming Universal Service Support:** Forgetting that these new keys might not be supported by *all* AWS services immediately. Always verify supported services in the AWS documentation before enforcing policies.
## Resources
* **AWS Documentation:** AWS global condition context keys (Reference for implementation syntax).
* **AWS Blog:** "Use scalable controls to help prevent access from unexpected networks" (Source for introductory examples).
* **Guardrail Framework:** Implement controls using AWS Service Control Policies (SCPs) and Resource Control Policies (RCPs) for organization-wide enforcement.