Customer Snapshot
| Attribute | Details |
|---|---|
| Industry | Workforce and services marketplace platform |
| Company Size | Roughly 300 employees |
| Cloud Environment | AWS, production and non-production accounts onboarded |
| Account Ownership | Accounts created under a billing partner’s AWS organization |
| Identity Provider | Google Workspace |
| Privileged Users | A small DevOps group with database and cluster access |
| Blocker | IAM Identity Center could not be enabled from inside the partner-managed org |
| Focus Area | Unblocking SSO-based just-in-time access |
The Situation: The Product Was Ready, the Organization Wasn’t
This team had already decided what they wanted: time-boxed access to production instead of standing privileges, approved by a named person and revoked automatically. They had the right people in the room, a clear use case for database access, and a plan.
What stopped them was not a product limitation. It was an organizational one.
Their AWS accounts had been created years earlier through a billing partner, a common arrangement for startups that buy cloud capacity through a reseller. The accounts belonged to the partner’s AWS Organization. That arrangement is invisible until you need something that only an organization’s management account can do.
Cloudanix JIT for AWS works through AWS IAM Identity Center. It grants access by assigning a user or group to a permission set for a limited window, then removing the assignment. That requires an Identity Center instance in the organization. When the team tried to enable one, AWS refused with an error stating that the organization’s management account does not allow member accounts to create instances. They didn’t own the management account, so they couldn’t change the answer.
To make matters more delicate, the team was already hesitant. Their identity provider is Google Workspace, not an AWS-native directory, and with only a few people needing privileged access, they questioned whether adding an Identity Center layer made sense at all.
The Core Tension
Two reasonable instincts pulled in opposite directions. Security wanted standing access gone. Engineering did not want to introduce a new identity layer for three people, and could not introduce it even if they wanted to.
The usual advice, “just enable Identity Center,” assumes you control the organization. This team did not. Waiting for the billing partner to change policy was not a plan, because the partner serves many customers and has no reason to alter how its organization is configured for one of them. The real question was: how do you get to an organization you control, with the least disruption, and how do you do it without rebuilding the identity stack?
Where the Gaps Were
Ownership of the Organization, Not Just the Accounts
Owning an AWS account and owning its organization are different things. Billing, consolidated invoicing, and SCPs sit with the management account. In a reseller arrangement, those belong to someone else. Identity Center is an organization-level service. Without management-account rights there is nothing to configure.
A Failing Error With No Obvious Next Step
The AWS message is accurate but unhelpful: it tells you what is not allowed, not what to do about it. Teams often lose weeks here, retrying the console, opening support cases against the wrong party, or assuming the integration is at fault.
Uncertainty About Whether Identity Center Was Worth It
For a company where three people hold database access, the instinct to avoid new infrastructure is healthy. But the question was being asked without a clear picture of what Identity Center would add, which is a single place where access is assigned and removed, and no standing permission sets for a human to carry around.
Standing Access in the Meantime
While the SSO question was open, privileged access continued the way it always had. Anything that waited on the organization move was, by definition, still standing access.
How Cloudanix Addresses This Situation
Step 1: Take Ownership of the Organization
The team raised a request with the billing partner to move their accounts into an AWS Organization the company controls. In AWS terms, the accounts leave the partner’s organization and join a new one whose management account the customer owns. The partner continues to provide billing and support if the commercial relationship stays, since many resellers operate on that basis, but the technical control plane returns to the customer. Cloudanix assisted by documenting what the move changes and what it doesn’t, so the team could ask the partner for precisely the right thing.
Step 2: Enable Identity Center in the New Organization
With management-account rights, enabling IAM Identity Center is a short step. The team created the instance in their primary region and chose their identity source.
Step 3: Keep Google Workspace as the Source of Truth
The team didn’t have to abandon Google Workspace. Identity Center can take users and groups from an external IdP over SAML and SCIM, so engineers continue to sign in with the account they already have. Group membership in Google Workspace maps to Identity Center groups, and Cloudanix works on top of that. There is no new directory to maintain and no second set of passwords.
Step 4: Enable Cloud JIT on Top
Cloudanix Cloud JIT reads the Identity Center structure: accounts, permission sets, and groups. An engineer requests a specific permission set on a specific account for a stated duration. An approver reviews and approves. Cloudanix assigns the permission set for the window and removes it at expiry. Engineers keep using the same AWS access portal they already know.
Step 5: Extend to Databases Through the Same Identity Layer
Once access is brokered through Identity Center, Database JIT uses the same identities. The engineer’s IAM Identity Center role grants permission to reach the proxy service, and database login uses short-lived tokens rather than a stored password.
What the Rollout Looked Like
- Diagnose the error properly. Confirm the accounts’ organization and the management account owner. If it isn’t you, stop troubleshooting the console.
- Request the organization move. Ask the partner to transfer the member accounts to the customer’s organization, and agree on timing and any billing changes.
- Prepare for the cutover. Check which SCPs, tag policies, and consolidated-billing arrangements will change. Confirm no workloads depend on partner-managed roles.
- Enable Identity Center and connect Google Workspace.
- Create permission sets that match real roles, such as read-only, developer, and database access, and map them to groups.
- Onboard Cloudanix and start with non-production before turning on production approvals.
- Retire the old access path. Remove direct IAM users and long-lived roles for people once JIT is the route.
Is It Worth It for a Small Privileged Group?
The team’s scepticism was fair, so it is worth answering directly. The cost of Identity Center is small: it is a free AWS service, and the work is a one-time setup. What it buys is the property that matters here: privileged access exists only while someone is actively using it, and every grant is tied to a named human and an approver. For three people with access to production databases holding personal and payment-related data, that is exactly the access you want to be temporary. The size of the group does not reduce what an attacker gains from one of those credentials.
What to Know Before You Start
- Moving accounts between organizations is an AWS Organizations operation that requires coordination with the partner. It does not interrupt running workloads, but it changes billing, and some partner-provided benefits such as discounts, support plans, or enrolled programs may not transfer. Clarify these before the move.
- Cloudanix JIT does not need to replace your IdP. Google Workspace remains the source of identity.
- Expect a short delay after creating users or groups before they appear in Cloudanix, because the data syncs on a schedule. Use the refresh option and plan the first live test accordingly.
- If you can’t move organizations, ask about other options early. Some access surfaces do not depend on Identity Center, but cloud-console JIT does.
Platform Impact
| Dimension | Before | After |
|---|---|---|
| Organization control | Held by billing partner | Held by the customer |
| IAM Identity Center | Blocked by AWS error | Enabled, sourced from Google Workspace |
| Privileged access | Standing | Time-boxed, approved, auto-revoked |
| New directories to maintain | N/A | None; existing IdP stays |
| Engineer experience | Direct credentials | Same AWS access portal |
| Audit of who had what and when | Informal | Identity-stamped request and approval history |
Key Outcomes
- ✅ Root Cause Resolved: The blocker was organizational, and it was fixed at the organizational level.
- ✅ Existing IdP Kept: Google Workspace remains the single source of identity.
- ✅ Zero Standing Privilege: Production access granted only for an approved window.
- ✅ Same Engineer Workflow: Same AWS access portal and tools.
- ✅ Foundation for More Surfaces: Database access builds on the same identity layer.
Stuck Behind a Reseller’s AWS Organization?
If Identity Center won’t enable and you don’t control the management account, you are not blocked by JIT. You are blocked by who owns the organization. Cloudanix can help you plan the move and have just-in-time access running on the other side.
Book a Free Assessment to map your account structure and the quickest route to JIT in under 30 minutes.
Related Resources
- JIT Cloud for Multi-Account AWS Organizations: SSO and Permission Sets
- Replacing StackStorm and Jira-Based Access Workflows with JIT for AWS Identity Center
- Implementing JIT Access in AWS, Azure & GCP: Complete Guide for Security Leaders
- What is Just-In-Time (JIT) Access?
- What is Zero Standing Privilege?
