Azure BYOC Setup Playbook
This guide explains how to prepare your Azure environment so Viven can deploy and operate Digital Twin in your cloud.
In this model:
- Customer data and logs stay in your Azure subscription
- Viven deploys and manages the Digital Twin platform stack
- Your team keeps control over subscription boundaries, networking, IAM/RBAC, and compliance posture
At any point, contact your Viven representative or support@viven.ai.
Overview
| Step | Task | Owner |
|---|---|---|
| 1 | Create a clean Azure subscription for Digital Twin | Customer |
| 2 | Configure RBAC and share deployment inputs | Customer |
| 3 | Confirm readiness and start deployment | Customer + Viven |
| 4 | Validate domains and add DNS records | Customer |
Prerequisites
Before you begin, confirm:
- You can create a new Azure subscription (recommended)
- Billing is active for that subscription
- You have an Azure admin who can assign subscription-level roles
- Your DNS owner can create TXT/CNAME records
- Your security team can review cross-cloud/OIDC requirements used during deployment
Viven recommends a dedicated Azure subscription for BYOC deployments to reduce conflicts with existing enterprise policies and resources.
Cross-cloud access requirements (security review)
For Azure BYOC deployments, Viven automation may pull release images/artifacts from Viven-controlled AWS resources using short-lived role-based access (no static keys), then deploy those releases into your Azure resources (for example ACR, App Service, AKS).
In restrictive environments, confirm:
- Azure identities used by deployment automation can perform required subscription/resource-group actions
- OIDC-based federation and outbound access needed for release retrieval are not blocked
- Your RBAC and policy controls allow Viven-managed deployment workflows
1. Create a dedicated Azure subscription
- Sign in to Azure Portal
- Open Subscriptions
- Click + Add / Create
- Select the subscription offer type (EA, PAYG, etc.)
- Review and create
2. Grant RBAC access and share kickoff details
2.1 Create managed identity prod-dt
- In Azure Portal, open Managed Identities
- Click Create
- Set Name to
prod-dt - Select your target subscription/resource group and create the identity
2.2 Grant required role assignments (subscription scope)
Grant the following roles at the subscription level:
- Contributor
- User Access Administrator (for assigning roles)
Assign these roles to:
- Viven infrastructure team
- Managed Identity (
prod-dt)
2.3 Share kickoff inputs with Viven
| Required detail | Example |
|---|---|
| Company name + preferred domain | Acme Inc, acmeinc.com |
| Azure subscription ID | 00000000-0000-0000-0000-000000000000 |
| Azure tenant ID | 11111111-1111-1111-1111-111111111111 |
| Target Azure region | westus2 |
| Resource group naming preference | rg-digitaltwin-prod |
| Identity and role assignments completed | prod-dt created and Contributor + User Access Administrator assigned at subscription level |
3. Notify Viven to start the build
Once steps 1-2 are complete, notify your Viven team. Viven then runs automated infrastructure provisioning and validates environment readiness.
After infra is ready, onboarding continues with:
- Connector setup
- SSO setup → (self-serve in Admin Console → SSO Setup)
- LLM configuration
- Pilot user rollout and governance controls
4. Configure custom domains after provisioning
Run these steps only after Viven confirms infrastructure provisioning is complete.
Typical domain pattern:
- Production:
digitaltwin.yourdomain.com - Staging:
stage-digitaltwin.yourdomain.com
Front Door domain validation usually requires:
| Record Type | Host/Name | Value Source |
|---|---|---|
| TXT | _dnsauth.<subdomain> | Validation token shown in Azure Front Door |
| CNAME | <subdomain> | Front Door endpoint (*.azurefd.net) |
Domain validation checklist
- Open Azure Front Door and find your custom domain in Pending state
- Add the TXT validation record in your DNS provider
- Wait for status to become Approved
- Add/verify CNAME to Front Door endpoint
- Validate origin routing/health (for example AKS origin via Private Link Service where configured)
Appendix
Core Azure services used by Digital Twin
| Azure Service | Purpose |
|---|---|
| Azure Front Door | Secure global edge distribution |
| Azure Kubernetes Service (AKS) | Worker/search workloads and selected app workloads |
| Azure Private Link Service (PLS) | Private origin exposure to Front Door |
| Azure Virtual Machines | Compute instances and Airflow runtime |
| Azure Synapse Analytics | Application/access log analytics |
| Azure Database for MySQL Flexible Server | User/configuration data store |
| Azure Database for PostgreSQL Flexible Server | Dedicated Airflow metadata database |
| Azure DNS | DNS management |
| Azure Managed Redis | Low-latency caching layer |
| Azure Cosmos DB | Primary processed-document datastore |
| Azure Container Registry (ACR) | Container image registry |
| Azure Blob Storage | Raw docs, artifacts, and release payloads |
| Microsoft Entra ID (Azure AD) | Identity and access management |
| Azure Key Vault | Secret storage |
| Azure Service Bus | Background task queues |
| Azure Event Hubs | Log stream transport |
| Azure Stream Analytics | Event processing into analytics stores |
| Azure Monitor | Metrics, logs, alerting |
Logs and operational access
Application logs and configuration data stay in your Azure environment. Viven support tooling uses controlled role-based access to diagnose incidents, validate deployments, and enable approved features.