What is the difference between Amazon Cloud Directory and AWS Directory Service?

Amazon Cloud Directory is a platform for building hierarchical data structures inside applications, such as org charts, machine registrations, or catalogs. AWS Directory Service is a managed cloud instance of Active Directory used for authentication and single sign-on. One is for storing structured relationships, while the other is for extending directory-based identity into AWS.

What each service is for

Amazon Cloud Directory and aws directory service solve different problems, even though both relate to “directory” concepts. Cloud Directory is a flexible data store for hierarchical relationships inside an application. AWS directory service is a managed directory platform for authentication, group membership, and single sign-on, most often by extending Microsoft Active Directory into AWS.

The practical difference is that Cloud Directory models data, while AWS Directory Service manages identity and access. If you need to represent org charts, device inventories, or product catalogs, Cloud Directory is the better fit. If you need users, groups, logon, and domain-based access to AWS or connected systems, AWS Directory Service is the relevant service.

That distinction matters because the two services answer different design questions. Cloud Directory is about how information is organized and retrieved. AWS Directory Service is about how people and systems prove who they are and inherit access from a directory authority.

How their security models differ

Cloud Directory is not an authentication system, so its main security concerns are data access, schema design, and protecting the integrity of relationships stored in the directory. AWS Directory Service, by contrast, sits in the access path, so its security posture affects authentication strength, administrative control, and whether directory permissions are aligned with least privilege.

That means the failure modes are different. With Cloud Directory, the main concern is incorrect or overly permissive application logic around the stored structure. With AWS Directory Service, the main concern is identity compromise, weak directory governance, or misconfigured trust that lets the wrong user or system reach AWS resources.

A useful way to think about it is this: Cloud Directory is closer to an application data model, while AWS Directory Service is closer to enterprise identity infrastructure. One is used by applications that need structured relationships; the other is used by environments that need directory-backed access control and user authentication.

For identity-centric practitioners, the AWS side is the one that aligns with directory governance and authentication controls. NHIMG’s Active Directory and Entra ID Hardening Guide is the more relevant internal reference when the real question is how directory-based access should be secured.

Which one to choose in practice

Choose Cloud Directory when your application needs a scalable hierarchy or graph-like structure, but does not need directory login semantics. Choose AWS Directory Service when your goal is to use or extend a traditional directory for authentication, authorization, or single sign-on in AWS.

In other words, Cloud Directory is the better fit for application data relationships, and AWS Directory Service is the better fit for identity integration. If you are trying to centralize employee accounts, support domain join, or connect AWS workloads to Active Directory, AWS Directory Service is the expected choice. If you are trying to store nested object relationships for a product or workflow, Cloud Directory is the better choice.

That choice also affects operational ownership. Cloud Directory usually belongs with application or platform teams designing a data model. AWS Directory Service usually belongs with identity or infrastructure teams managing authentication, trust boundaries, and access paths.

Risk and Threat Considerations

The main risk is using a directory-like service for the wrong job. If you treat Cloud Directory as if it were an identity control, you can end up with weak access enforcement. If you treat AWS Directory Service as if it were just another data store, you can underplay the blast radius of directory compromise or misconfiguration.

Failure mechanism: Confusing structured data storage with identity infrastructure can lead to broken assumptions about authentication, authorization, and trust. That can create overexposed data, excessive access, or an identity dependency that becomes a single point of failure.

Impact: The result can be unauthorized access, poor segregation of duties, or operational disruption if directory services are mismanaged or unavailable. In AWS environments, the impact is usually much larger when the directory is tied to login and access rather than just data organization.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST SP 800-53 Rev 5 and OWASP ASVS set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	IA-2 — Identification and Authentication (Organizational Users)	AWS Directory Service supports directory-backed user authentication.
	IA-9 — Service Identification and Authentication	Directory-backed AWS access often extends to services and workloads.
	AC-6 — Least Privilege	Directory-based access should limit who can reach AWS resources.
Recommendation — Use IA-2 to require strong user authentication through the directory. Use IA-9 to authenticate non-human systems that consume directory-backed access. Apply AC-6 to keep directory-granted permissions tightly scoped.
ISO/IEC 27001:2022	A.5.15 — Access control	The distinction between data hierarchy and identity access maps directly to access control design.
Recommendation — Define and enforce access control boundaries around directory-backed services.
OWASP ASVS	V8 — Authorization	The practical difference hinges on whether access is enforced or data is merely stored.
Recommendation — Verify that authorization is enforced in the application rather than implied by directory data.

Practitioner Guidance

What to verify: Before choosing between them, verify whether the requirement is to store relationships or to control access. If the system must authenticate users, federate access, or support domain-based privileges, the design belongs on the AWS Directory Service side.

Decision rule: If the directory is part of the trust chain, treat it as identity infrastructure and review authentication, admin access, and recovery procedures. If it only represents business objects or hierarchy, treat it as application data and focus on schema, consistency, and authorization in the consuming application.

Common mistake: Teams often pick a “directory” service based on the name rather than the security function. That leads to brittle architectures where data modeling and identity governance are mixed together, which makes both harder to secure and operate.

Practitioner takeaway: The fastest way to choose correctly is to ask whether the service must prove who someone is, or merely describe how things relate. If it must prove identity, it is an access problem, not a data-structure problem.