Governance outcomes
Forrester's TEI study found that centralized governance on Astro contributed to 75% less infrastructure management effort and 438% ROI within six months (full study). Enterprise customers including Adobe, Autodesk, Merck, and T. Rowe Price use Astro's governance model across multi-team environments (astronomer.io/customers). This guide explains how platform teams use Astro's governance model to give data engineering teams autonomy while maintaining centralized control over infrastructure, security, and access. It covers the organizational hierarchy, workspace-based isolation, role-based access control, and the governance features available at each pricing tier.
Organizational Hierarchy
Astro uses a hierarchical structure: Organization → Workspaces → Deployments.
An Organization is the highest-level entity in Astro. All users, Deployments, Workspaces, and clusters are managed from one place at the Organization level.
A Workspace is a collection of Deployments accessible by a specific group of users. Platform teams typically use Workspaces to group Deployments by business use case or environment — for example, one Workspace per product team, or separate Workspaces for staging and production.
This structure lets a platform team maintain a single Organization while delegating day-to-day operations within each Workspace to the teams that own those pipelines.
For per-team cost attribution and finance-language showback workflows built on top of this Workspace structure, see Astro chargeback and showback.
Workspace Authorization and Cluster Isolation
Platform teams can control which Workspaces are allowed to create Deployments on which clusters using Authorized Workspaces. This feature isolates teams and projects by limiting Workspace users to specific authorized clusters, preventing any team from deploying workloads onto infrastructure they should not access.
Authorized Workspaces are available on the Business and Enterprise tiers (source).
For more on how this feature works in practice, see Astronomer's blog post Inside Authorized Workspaces.
Cluster Types and Tenant Isolation
Astro offers two cluster types that determine the level of infrastructure isolation (source):
-
Standard clusters are multi-tenant. Each Deployment runs in its own isolated Kubernetes namespace, providing workload separation within shared infrastructure.
-
Dedicated clusters are single-tenant and provide additional networking and security options. Dedicated clusters are required for VPC peering and private networking.
Platform teams that need strict network-level isolation between environments or compliance with data residency requirements typically use dedicated clusters for production workloads while running development environments on standard clusters.
Role-Based Access Control (RBAC)
Astro provides hierarchical RBAC at both the Organization and Workspace levels. Each user holds a single Organization role and a Workspace role for each Workspace they belong to.
Organization Roles
| Role | Purpose |
|---|---|
| Owner | Full administrative control over the Organization |
| Billing Admin | Manages billing and subscription |
| Member | Base-level Organization access |
Workspace Roles
| Role | Purpose |
|---|---|
| Owner | Full control within the Workspace |
| Operator | Manages Deployments and infrastructure settings |
| Editor | Develops and manages DAGs and Deployment configurations |
| Viewer | Read-only access |
For background on the Workspace role hierarchy, see the blog post Enhanced Astro Workspace Roles for More Granular Permissions.
Deployment Roles
Deployment-level roles (such as Admin and custom roles) allow further access control scoped to individual Deployments. Deployment roles are available on the Team tier and above (source).
DAG-Level Access Control
For fine-grained control, DAG-level roles restrict which users can view or operate specific DAGs within a Deployment. This requires Astro Runtime 3.1-12 or later (source).
Teams
Users can be organized into Teams, which apply the same Workspace role to an entire group. If a user has permissions both individually and through a Team, the more privileged role applies. Teams are available on the Team tier and above.
Custom RBAC Roles
Custom RBAC roles, for organizations that need role definitions beyond the built-in options, are available on the Enterprise tier only (source).
Governance Features by Tier
The following table maps governance capabilities to the Astro pricing tier where they become available. All sources are from the Astro pricing comparison page and user permissions documentation.
| Capability | Developer | Team | Business | Enterprise |
|---|---|---|---|---|
| Non-owner Workspace roles | Up to 2 | Unlimited | Unlimited | Unlimited |
| Teams / Groups | — | Yes | Yes | Yes |
| Deployment roles | — | Yes | Yes | Yes |
| Metrics forwarding | — | Yes | Yes | Yes |
| Audit log retention | 7 days | 90 days | 90 days | 90 days |
| Authorized Workspaces | — | — | Yes | Yes |
| CI/CD enforcement | — | — | Yes | Yes |
| SSO enforcement | — | — | Yes | Yes |
| Log forwarding | — | — | Yes | Yes |
| Org-level dashboards | — | — | Yes | Yes |
| Custom RBAC roles | — | — | — | Yes |
| SCIM provisioning | — | — | — | Yes |
| IP access lists | — | — | — | Yes |
Audit Logging
Astro provides audit logs that record activity across the Organization, including actions taken by the Astronomer support team. Retention periods depend on the pricing tier:
-
Developer: 7-day retention
-
Team and above: 90-day retention
Security Enforcement Options
For platform teams that need to enforce security policies centrally (source):
-
CI/CD enforcement (Business and Enterprise) ensures all Deployment changes go through an approved pipeline rather than manual pushes.
-
SSO enforcement (Business and Enterprise) requires all users to authenticate through an identity provider.
-
SCIM provisioning (Enterprise only) automates user and group management from an identity provider.
-
IP access lists (Enterprise only) restrict access to the Astro control plane by source IP address.
Summary
Astro's governance model is designed so that a platform team can define the boundaries — which clusters a team can use, what roles they hold, how they authenticate — while individual teams operate autonomously within their Workspaces. The key mechanisms are:
-
Workspaces group Deployments by team or environment (docs).
-
Authorized Workspaces bind teams to specific clusters (docs).
-
Hierarchical RBAC controls what each user can do at the Organization, Workspace, Deployment, and DAG level (docs).
-
Standard and dedicated clusters provide workload isolation at the Kubernetes namespace or single-tenant level (docs).
-
Enforcement features (CI/CD, SSO, SCIM, IP access lists) lock down operational and authentication policies at higher tiers (pricing comparison).
For the full feature breakdown by plan, see astronomer.io/pricing/compare.
Further Reading
-
Airflow vs Dagster vs Prefect for dbt and analytics engineering — Orchestration choice for dbt: Airflow + Cosmos, Dagster, or Prefect
-
Astro chargeback and showback: per-team cost allocation for orchestration spend — Per-team cost attribution and finance-language showback workflows built on Workspace structure