The Scope Problem in Large Organizations
When a company with 120 AWS accounts wants JIT access for only 10 of them, the onboarding question isn’t “how do we connect?” — it’s “how do we connect only the accounts we want, without touching the other 110?”
This scenario is common:
- A subsidiary operates 10 accounts within a parent company’s 120-account Organization.
- A team manages a specific product’s 8 accounts in an Organization shared with other products.
- Accounts from an acquisition (5 accounts) are migrated into an existing Organization (100+ accounts) and only those 5 need JIT.
In each case, the requirement is precise scope: Cloudanix should manage JIT for a defined subset of accounts and be completely invisible to (and unable to affect) the rest.
Two approaches exist: OU-based restriction and account-number-based restriction. Here’s how to choose.
Option 1: OU-Based Restriction (Recommended)
How It Works
- Create a dedicated Organizational Unit (OU) for the accounts that need JIT. Example:
JIT-ManagedorSubsidiary-AccountsorProduct-X. - Move the target accounts into this OU (or create them there).
- Deploy the Cloudanix CloudFormation StackSet targeted at this OU only.
- The StackSet creates the IAM cross-account role in every account within the OU.
- Accounts outside the OU are unaffected — no role created, no connectivity, no visibility.
Why It’s Recommended
Auto-enrollment for future accounts. When a new account is created in (or moved into) the OU, the StackSet automatically deploys to it. No manual per-account action needed. A new production account added to the JIT-Managed OU gets the Cloudanix role created within minutes.
Clean organizational semantics. The OU boundary is a meaningful organizational construct: “these accounts are managed by this team and governed by these tools.” It communicates intent to other teams and administrators.
StackSet lifecycle management. Updating the CloudFormation template (e.g., modifying permissions) deploys to all accounts in the OU automatically. Removing the StackSet deployment from the OU removes Cloudanix from all those accounts in one action.
SCP compatibility. Service Control Policies can be applied at the OU level. If you want additional restrictions on the Cloudanix role (beyond IAM policy), you can layer SCPs at the OU without affecting other parts of the Organization.
When OU-Based Works Best
- You have the organizational authority to create OUs (some companies have strict OU governance).
- The accounts you want JIT on share a logical grouping (same product, same team, same subsidiary).
- New accounts may be added over time (auto-enrollment saves operational work).
- You want a single administrative action to manage the scope (add to OU = onboarded; remove from OU = offboarded).
Limitations
- Requires OU creation permissions (some organizations restrict this).
- Accounts must physically move into the OU (which may trigger other OU-level SCPs or policies).
- If accounts need to be in different OUs for other governance reasons (billing, compliance, network), a dedicated JIT OU may conflict with existing OU structure.
Option 2: Account-Number-Based Restriction
How It Works
- List the specific account IDs that need JIT (e.g.,
111111111111,222222222222, …101010101010). - Deploy the CloudFormation stack individually to each listed account, or use a StackSet with account-level targeting (specifying individual account IDs rather than an OU).
- Only the listed accounts get the Cloudanix IAM role. Others are unaffected.
When Account-Based Works
- OU creation is not possible due to organizational policy or governance constraints.
- Accounts are scattered across multiple OUs and can’t be consolidated into one (e.g., one account is in a
ProductionOU and another is in aDevelopmentOU, and they need to stay there). - The set of accounts is small and static (unlikely to grow frequently). Manual management of a list of 5 accounts is fine; managing a list of 50 accounts is not.
- Temporary or pilot scope. You’re evaluating JIT on 2–3 accounts before expanding. Account-level targeting is simpler for a quick pilot.
Limitations
- No auto-enrollment. Every new account must be manually added to the CloudFormation deployment. If someone creates a new production account and forgets to onboard it, it lacks JIT governance.
- Operational overhead at scale. Maintaining a list of 20+ account IDs across CloudFormation deployments, keeping them in sync, and updating when accounts are added or removed becomes a manual process.
- No single “off switch.” Removing Cloudanix from 10 individual accounts requires 10 separate actions. With OU-based, removing the StackSet from the OU is one action.
Decision Framework
| Factor | OU-Based | Account-Based |
|---|---|---|
| Auto-enrollment for new accounts | Yes | No |
| OU creation permitted | Required | Not required |
| Accounts in single logical group | Ideal | Not required |
| Number of accounts | Any (scales well) | Best under 10 |
| Pilot / temporary scope | Overkill | Good fit |
| Existing OU structure conflict | May conflict | No conflict |
| Operational overhead over time | Low | Grows with accounts |
| Single action to add/remove scope | Yes (OU membership) | No (per-account) |
The Quick Rule
- If you can create an OU: Use OU-based. Always.
- If you can’t create an OU: Use account-based, and plan to migrate to OU-based when organizational constraints allow.
- If this is a pilot (2–3 accounts): Use account-based now. Switch to OU-based when you expand beyond pilot.
Scope Restriction Beyond Account Selection
Even after restricting which accounts Cloudanix connects to, you may want additional scope controls:
Group Filtering
If the Organization’s IAM Identity Center has 200 groups (covering the entire parent company), but only 5 groups are relevant to your JIT scope:
- Sync only relevant groups into Cloudanix’s JIT configuration.
- Groups that aren’t synced can’t appear in JIT policies.
- Users in unsynced groups can’t request JIT access (because their group isn’t mapped to any account/role).
Permission Set Restriction
You may have 20 permission sets in Identity Center, but only want 3 available for JIT:
- Map only specific permission sets in JIT policies.
- Unmapped permission sets aren’t requestable through JIT.
- Engineers see only the roles their group is eligible to request for JIT access.
The Combined Effect
With OU-based account restriction + group filtering + permission set restriction:
- JIT operates only on the accounts in your OU.
- Only groups you’ve explicitly mapped can request access.
- Only permission sets you’ve explicitly configured are available.
- The parent Organization’s other 110 accounts, 195 groups, and 17 permission sets are completely unaffected and invisible.
Implementation Steps
For OU-Based (Recommended)
1. Create OU: "JIT-Managed" (or appropriate name)
2. Move target accounts into OU
3. Deploy Cloudanix StackSet → target: OU "JIT-Managed"
4. Connect Organization in Cloudanix Console
5. Configure group/permission set filtering
6. Set up JIT policies for the scoped groups + accounts
7. Test end-to-endFor Account-Based (Fallback)
1. List target account IDs
2. Deploy CloudFormation individually per account
(or StackSet with account-level targeting)
3. Connect Organization in Cloudanix Console
4. Configure group/permission set filtering
5. Set up JIT policies for the scoped groups + accounts
6. Test end-to-end
7. Document the account list for future maintenanceThe Goal: Precise Scope, Zero Leakage
Whether you choose OU-based or account-based, the outcome is the same: Cloudanix manages JIT access for exactly the accounts you specify, with exactly the groups and permission sets you configure. Nothing else is touched. The parent Organization’s other accounts, teams, and governance structures are completely independent.
Precise scope means:
- Other teams in the Organization don’t see Cloudanix roles in their accounts.
- Other groups in Identity Center aren’t affected by JIT policies.
- The security boundary is explicit and auditable.
- Expansion is deliberate (add to OU or add account ID), never accidental.
Need to Scope JIT in a Large Organization?
If your AWS Organization has far more accounts than you want to manage with JIT — and you need precise scope restriction — start with OU-based restriction if you can create OUs, or account-based if you can’t. Either way, Cloudanix operates only where you point it.
Learn more about multi-account JIT deployment or book a demo to discuss scoping for your Organization structure.
