# Managed BYOC In a **managed** [BYOC](https://docs.diagrid.io/operate/hosting/byoc) region, the Catalyst data plane runs in your own cloud account and Diagrid provisions and operates it for you. You grant Diagrid scoped access to your account through a **cloud connection**, and from there the experience is the same as [Dedicated Cloud](https://docs.diagrid.io/operate/hosting/dedicated-cloud) — one command, no infrastructure to build or maintain. If you'd rather run the Catalyst data plane on a Kubernetes cluster you operate yourself, use [self-managed BYOC](https://docs.diagrid.io/operate/hosting/enterprise-self-hosted) instead. ## How it works 1. You create a **cloud connection** — an organization-level resource that records how Diagrid accesses your cloud account: an IAM role on AWS, or a federated app identity on Azure. 2. You create a region through that connection. Diagrid's provisioner uses the connection's identity to create the region's infrastructure in your account — networking, a Kubernetes cluster, a database, and the region's own IAM roles — then deploys the Catalyst data plane and joins the region to your organization. 3. Diagrid operates the region from then on: upgrades, scaling within the tier, and lifecycle management, all inside your account. Managed BYOC regions are available on AWS and Azure. ## Grant Diagrid access **AWS** On AWS, the cloud connection points to an IAM role in your account that Diagrid's provisioner assumes. 1. Create the cloud connection: ```bash diagrid cloudconnection create my-aws-account --provider aws ``` 2. In the Catalyst console, go to **Cloud providers** and open the connection you just created. The console displays ready-to-run **AWS CLI** and **Terraform** snippets with the exact trust policy pre-filled for your environment. Run the snippet in a terminal signed in to the AWS account you want Diagrid to provision into. The snippet creates an IAM role named exactly `diagrid-dedicated-region-provisioner` with permissions scoped to what Diagrid provisions: EC2 networking, the EKS cluster, the RDS database, and the region's own IAM roles — not administrator access. It also creates a second, customer-owned role, `diagrid-cluster-operator`, so your platform team can inspect the region's EKS cluster with `kubectl` without going through Diagrid. 3. Record the role on the connection: ```bash diagrid cloudconnection update my-aws-account \ --role-arn arn:aws:iam::123456789012:role/diagrid-dedicated-region-provisioner ``` The role name must match exactly — Diagrid's provisioner is only permitted to assume a role with this name in your account, so a differently named role can never be assumed. **Azure** On Azure, there is no role assumption. Instead, you register an application in your Microsoft Entra tenant and add **federated identity credentials** that trust Diagrid's provisioning platform. Each federated credential matches exactly one subject, so onboarding adds several credentials to the same app registration rather than a single one. 1. Create the cloud connection: ```bash diagrid cloudconnection create my-azure-sub --provider azure ``` 2. In the Catalyst console, go to **Cloud providers** and open the connection you just created. The console displays ready-to-run **Azure CLI** and **Terraform** snippets with the exact issuer, subjects, and role assignments pre-filled for your environment. Run the snippet in a terminal signed in to the Azure subscription you want Diagrid to provision into. The snippet creates an Entra app registration named `diagrid-dedicated-region-provisioner` with seven federated identity credentials (one per Diagrid provisioning component), a service principal, and two role assignments on your subscription: **Contributor** (to create the region's infrastructure) and **User Access Administrator** (to create the region's workload identities). The app never gets a client secret — authentication is entirely federated. 3. Record the three identifiers the snippet prints on the connection: ```bash diagrid cloudconnection update my-azure-sub \ --tenant-id \ --subscription-id \ --client-id ``` Nothing is validated when the connection is created — the credentials are first exercised when you create a region through the connection, so check the region's status closely on your first attempt. You can't create a region through a connection until its identity is recorded. ## Create the region Create the region through the console — under **Regions**, select **Create region**, choose **BYOC**, then **Managed** — or with the CLI: **AWS** ```bash diagrid region create my-region \ --byoc \ --cloud-connection my-aws-account \ --cloud aws \ --region eu-west-1 \ --tier small ``` **Azure** ```bash diagrid region create my-region \ --byoc \ --cloud-connection my-azure-sub \ --cloud azure \ --region westeurope \ --tier small ``` The `--cloud` value must match the cloud connection's provider. The sizing tiers (`small`, `medium`, `large`, `xlarge`) and networking postures (`public`, `private`) work the same way as for [Dedicated Cloud](https://docs.diagrid.io/operate/hosting/dedicated-cloud#what-you-choose-what-diagrid-manages). ## Track provisioning Provisioning typically takes 20–40 minutes and moves through the same phases as a dedicated region — `Pending`, `Provisioning`, `Deploying`, `Joining`, `Ready`: ```bash diagrid region get my-region ``` If Diagrid can't provision into your account — for example, the provisioner role can't be assumed or is missing a permission — the region fails fast and its status message tells you why, so you can fix the connection and retry. ## Start using the region Once the region reports `Ready`, create a project in it: ```bash diagrid project create my-project --region my-region ``` To make it the default region for every new project in your organization, use [`diagrid region use`](https://docs.diagrid.io/references/catalyst/cli-reference/region/use). From here, run any [quickstart](https://docs.diagrid.io/getting-started/quickstarts) against your new project to verify the region end to end. ## Operate the region Day-to-day, a managed BYOC region behaves like a dedicated region that happens to live in your account: - Diagrid runs and upgrades the data plane and the underlying infrastructure. - Your team keeps independent access to the cluster through the `diagrid-cluster-operator` role on AWS. - Resize or change networking with [`diagrid region update`](https://docs.diagrid.io/references/catalyst/cli-reference/region/update). ## Support plans A managed BYOC region can be purchased with the `select` or `premium` support plan, set with the `--support-plan` flag on [`diagrid region create`](https://docs.diagrid.io/references/catalyst/cli-reference/region/create). Regions running on your own infrastructure start at `select`. The region's price reflects its sizing tier and support plan together. See [Plans & support](https://docs.diagrid.io/operate/plans-and-support) for what each plan covers. ## What's next - [Dedicated Cloud](https://docs.diagrid.io/operate/hosting/dedicated-cloud) — the same managed experience in Diagrid's cloud. - [Self-managed BYOC](https://docs.diagrid.io/operate/hosting/enterprise-self-hosted) — run the data plane on your own Kubernetes cluster. - [Projects](https://docs.diagrid.io/operate/platform-operations/projects) — create projects inside your new region.