Choose based on the problem you need to solve. A cloud data hierarchy service is for building structured relationships between objects inside an application or data model. A managed directory service is for using existing directory data to authenticate users and servers in AWS, and to extend sign-on into AWS applications. The distinction matters because they solve different identity and data management needs.
How to choose the right AWS service for the job
The decision should start with the underlying control problem, not the AWS product category. If you need to model relationships inside an application or data structure, the cloud data hierarchy service fits. If you need to authenticate people or servers against existing directory identities and extend sign-on into AWS, the managed directory service is the better fit.
That distinction matters because the first is about structuring data, while the second is about identity, authentication, and access to AWS resources. Security teams should avoid forcing one service to do the other’s job, because that usually creates brittle integrations, weak trust boundaries, or unnecessary directory dependence.
When a cloud data hierarchy service is the better fit
Use the hierarchy service when the problem is domain modelling: parent-child object relationships, inheritance-like structure, or navigation across related records inside an application. The control question is whether the data needs to be organized and queried in a structured tree or graph-like pattern, not whether a user should be able to log in.
For security teams, the practical test is whether the service is holding application data that may influence downstream decisions, such as entitlements, configuration, or workflow state. If the hierarchy is only a container for business objects, treat it as a data design choice and keep identity controls elsewhere. For workload access patterns and temporary credentials in AWS, a Cloud Workload Identity Guide is the more relevant reference than a directory service discussion.
Do not stretch a hierarchy service into authentication just because the application stores user-shaped records. If the application only needs to know who belongs to which group or node, that is still a data model issue. If it must prove identity or authorize access, the design has crossed into access management and should be handled accordingly.
When a managed directory service is the better fit
Use the managed directory service when AWS workloads need to rely on established directory identities, Kerberos or LDAP-style authentication patterns, or AWS-integrated sign-on for users and servers. This is the right choice when the goal is to extend existing identity infrastructure into AWS rather than recreate identity data inside an application.
That makes it a security control as much as a platform service. A managed directory service affects authentication flow, trust relationships, and how access is granted to AWS-hosted systems. If the directory is the source of truth for identity, then its availability, synchronization, and delegation boundaries become material to the AWS environment. For background on hardening directory and service-account dependencies, the Active Directory and Entra ID Hardening Guide is a useful companion.
It is also important not to confuse directory integration with simple application membership lists. If the AWS service is authenticating a human user, server, or service account, the directory service belongs in the design. If the service is only storing hierarchical attributes for business logic, the directory service is usually the wrong abstraction.
What security teams should verify before deciding
The most useful decision point is whether the AWS requirement is about service account security, user authentication, and sign-on, or about data relationships inside the application. Security teams should ask who or what is being trusted, what authority is being delegated, and whether the control failure would expose identities or only corrupt data structure.
They should also check whether the directory is an operational dependency. If authentication must continue during directory outages, the resilience requirements are different from a pure data hierarchy service. If the relationship is cross-account, cross-application, or involves privileged access, the design should be reviewed as an access control problem rather than only a platform selection problem. In AWS environments, identity and workload trust often depend on temporary credentials and role-based access, which is why the AWS workload identity model matters when the design touches access paths.
For the broader threat model behind cloud credential abuse and exposed secrets, an incident write-up such as 230M AWS environment compromise is useful because it shows how quickly mis-scoped cloud access becomes an attack path.
Risk and Threat Considerations
Cloud teams often create risk when they let a directory service absorb application-model responsibilities, or when they let a hierarchy service stand in for authentication. The first error can expose too much trust in a shared identity source, while the second can leave access decisions fragmented across application code and inconsistent controls.
Failure mechanism: The control fails when identity data, authentication logic, and application relationships are blended into one service boundary, making privilege checks, lifecycle management, and auditability harder to govern.
Impact: The result can be excessive access, brittle integrations, broken sign-on, or a directory dependency that expands blast radius across multiple AWS workloads.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CSA Cloud Controls Matrix, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CSA Cloud Controls Matrix | IAM — Identity & Access Management | AWS directory choice directly affects identity, authentication, and access control. |
| Recommendation — Align AWS identity sources and access paths under IAM controls with clear authority boundaries. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Managed directory service authenticates users and servers in AWS environments. |
| IA-9 — Identification and Authentication (Service and Workload Access) | AWS service-to-service and server trust often depend on managed directory-backed authentication. | |
| AC-6 — Least Privilege | The choice affects how much access identities receive inside AWS and to adjacent systems. | |
| Recommendation — Use IA-2 to ensure organizational identities are authenticated before AWS access is granted. Apply IA-9 to authenticate services and workloads with scoped, verifiable credentials. Enforce AC-6 so directory-integrated access remains narrowly scoped to business need. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust Architecture | The decision turns on trust boundaries, identity verification, and access enforcement in AWS. |
| Recommendation — Use zero trust principles to separate identity authority from application data relationships. | ||
Practitioner Guidance
What to prioritise: Decide first whether the system needs identity authority or data structure. If the answer is authentication, federation, or server trust, use the directory service. If the answer is relationship modelling inside an app, use the hierarchy service.
What to verify: Confirm where the source of truth lives for identities, groups, and access rules. Then verify whether AWS must trust that source at runtime, or only consume its data for application logic. That check usually exposes the wrong abstraction quickly.
Common mistake: Teams often choose the service that looks more flexible and then retrofit security later. In practice, that is how directory sprawl and access ambiguity appear, especially when multiple AWS applications start depending on the same trust path.
Practitioner takeaway: Choose the service that matches the governing question, not the one that seems closer to your implementation stack. If the decision affects who can authenticate or gain access, treat it as an identity design choice; if it only affects how objects relate, treat it as a data modelling choice.
Related resources from NHI Mgmt Group
- How should security teams decide between a data platform and a managed ML service for production AI workloads?
- How should security teams decide between service principals and managed identities in Azure?
- How should security teams decide between static and dynamic data masking in SaaS, cloud, and AI workflows?
- How do security and platform teams decide between a managed agent service and a control plane approach?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 28, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
