Access control is the mechanism that translates identity into authorization — determining not just who someone is, but what they are allowed to do. As cloud environments grow in complexity, the choice of access control model becomes a critical architectural decision with implications for security, operational efficiency, and the ability to scale. Three dominant models exist: Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), and the increasingly relevant Relationship-Based Access Control (ReBAC).
Each model embodies a different philosophy about how permissions should be structured and evaluated. None is universally superior; each has strengths that align with specific organizational patterns and weaknesses that create friction in the wrong context. Understanding these trade-offs is essential for building an IAM architecture that is both secure and maintainable as your cloud footprint grows.
Role-Based Access Control: The Established Standard
RBAC assigns permissions to roles, and roles are assigned to users. A developer role might carry permissions to deploy code and read logs; an analyst role might carry permissions to query data warehouses and view dashboards. This indirection — user to role to permission — simplifies administration because you manage a relatively small number of roles rather than individual user-permission mappings. Every major cloud provider uses RBAC as its foundational access control model, and most enterprise identity platforms are built around role assignment.
The strength of RBAC lies in its simplicity and auditability. It is straightforward to answer the question 'what can this user do?' by examining their role assignments. Compliance teams find RBAC intuitive because roles map naturally to job functions, making it easy to demonstrate separation of duties and appropriate access levels. For organizations with well-defined job functions and moderate cloud complexity, RBAC provides an effective, understandable access control framework.
However, RBAC struggles with scale and granularity. As the number of resources, environments, and access patterns grows, the number of roles required to express fine-grained permissions explodes — a problem known as role explosion. An organization that needs distinct access levels across four environments, three cloud providers, and twenty services may find itself managing hundreds or thousands of roles. At that point, the simplicity that made RBAC attractive is replaced by an unwieldy role hierarchy that is difficult to audit and prone to permission creep.
Attribute-Based Access Control: Dynamic and Contextual
ABAC evaluates access decisions based on attributes of the user, the resource, the action, and the environment. Rather than assigning a static role, ABAC policies express rules like 'engineers in the payments team can read production databases tagged as payments-owned during business hours from corporate IP ranges.' Each element of that rule is an attribute: team membership, resource tag, time of day, and network location. The access decision is computed dynamically at request time by evaluating the policy against current attribute values.
This dynamic evaluation makes ABAC exceptionally flexible. A single ABAC policy can replace dozens of RBAC roles by expressing the access logic in terms of attributes rather than static assignments. AWS IAM policies with conditions, Azure conditional access policies, and GCP IAM conditions all provide ABAC capabilities. ABAC also adapts naturally to environmental context — you can enforce stricter access from untrusted networks, limit administrative actions to maintenance windows, or restrict access based on data classification tags without creating new roles for each scenario.
The trade-off is complexity in policy design and auditability. ABAC policies are harder to reason about because the effective permissions depend on runtime attribute values. Answering 'what can this user do?' requires evaluating all applicable policies against all possible attribute combinations, which can be computationally and cognitively expensive. Organizations adopting ABAC need strong policy modeling tools, thorough testing practices, and clear attribute governance to avoid creating policies that are technically correct but practically incomprehensible.
Relationship-Based Access Control: Modeling Real-World Structures
ReBAC is the newest of the three models and derives authorization from the relationships between entities. Rather than asking 'does this user have a role on this resource?' (RBAC) or 'do the attributes satisfy the policy?' (ABAC), ReBAC asks 'does a relationship path exist between this user and this resource that grants the requested permission?' Google's Zanzibar system, which underpins Google Drive, Google Cloud, and YouTube authorization, is the most prominent implementation. Open-source projects like OpenFGA, SpiceDB, and Ory Keto make ReBAC accessible to broader adoption.
ReBAC excels in scenarios where access is naturally hierarchical or graph-structured. If a user is a member of a team, and that team owns a project, and that project contains a resource, then the user has access to the resource through the relationship chain. This mirrors how organizations actually think about ownership and access. ReBAC also handles sharing and delegation elegantly — granting a collaborator access to a document is simply adding a relationship, which the system evaluates as part of the authorization graph.
The primary challenge with ReBAC is infrastructure complexity. It requires a dedicated authorization service that maintains the relationship graph and evaluates queries against it with low latency. This is a significant architectural investment compared to the policy-based evaluation that RBAC and ABAC use natively within cloud provider IAM. ReBAC is most justified for application-level authorization in SaaS products and multi-tenant platforms where the relationship model is central to the product's access semantics.
Practical Recommendations for Mid-Market Organizations
For most mid-market organizations operating in cloud environments, the optimal approach is a layered strategy rather than a single-model commitment. Use RBAC as the foundation for cloud provider IAM — defining roles for infrastructure access that align with job functions and operational responsibilities. This leverages the native capabilities of AWS, Azure, and GCP without requiring additional tooling and provides the auditability that compliance frameworks expect.
Layer ABAC on top of RBAC where you need contextual controls or finer granularity without role explosion. Tag-based access policies that restrict resource access based on environment (production vs. development), data classification (public vs. confidential), or team ownership can dramatically reduce the number of roles needed while adding meaningful security controls. Most cloud providers support this layering natively through IAM policy conditions.
Consider ReBAC if you are building a multi-tenant application or a platform where user-to-resource relationships are the natural access model. For infrastructure IAM, ReBAC is typically over-engineered. The key principle is to match the access control model to the problem structure: RBAC for stable, well-defined job-function access; ABAC for dynamic, context-dependent controls; and ReBAC for relationship-driven application authorization.