AWS BYOC Setup Playbook
This guide explains how to prepare your AWS environment so Viven can deploy and operate Digital Twin in your cloud.
In this model:
- Customer data and logs stay in your AWS account
- Viven deploys and manages the Digital Twin platform stack
- Your team keeps control over account boundaries, IAM, networking, and compliance posture
At any point, contact your Viven representative or support@viven.ai.
Overview
| Step | Task | Owner |
|---|---|---|
| 1 | Create a clean AWS account for Digital Twin | Customer |
| 2 | Create access identities and share kickoff details | Customer |
| 3 | Create ACM certificates and share ARNs/domain | Customer |
| 4 | Share SCP, proxy, or networking constraints | Customer |
| 5 | Confirm readiness and start deployment | Customer + Viven |
Prerequisites
Before you begin, confirm:
- You can create a new AWS account under your AWS Organization
- Billing is enabled for the new account
- You have an AWS admin contact who can create IAM roles
- Your DNS owner can create/validate ACM certificates
- Your security team can review any cross-account policy constraints (SCP/IAM/VPC endpoint policy)
Viven strongly recommends a new, dedicated AWS account for BYOC deployments to avoid policy and networking conflicts with pre-existing workloads.
Cross-account deployment requirements (security review)
Viven deployment automation distributes release artifacts from a central AWS account and deploys them into your account. In restrictive environments, ensure your policies permit:
- Read access to Viven-provided container images in central ECR
- Read access to release/config artifacts in central S3
- Role assumption needed for deployment orchestration and break-glass support
Most customers do not need custom changes, but organizations with strict SCPs or explicit deny policies should review this before kickoff.
Release integrity and trusted upgrades
Viven follows a controlled release process for BYOC environments so only approved software is deployed.
- Viven uses AWS Signer to sign release images
- Releases are built and approved through Viven's trusted software delivery workflow
- Deployment automation in your AWS environment accepts only approved releases
- Integrity checks are performed before rollout
- If integrity validation fails, the rollout is blocked automatically
This gives your security team stronger assurance that production upgrades come from Viven-approved releases and have not been altered in transit.
1. Create a dedicated AWS account
Create a new sub-account in AWS Organizations for Digital Twin.
- Sign in to your AWS management account
- Open AWS Organizations
- Go to Accounts → Add an AWS account
- Select Create an AWS account and enter:
- Account name: for example
DigitalTwin-Prod - Email: distribution/admin email you control, for example
aws-admin@yourdomain.com
- Account name: for example
- Complete account creation and wait for it to appear in your org
2. Grant Viven access and share kickoff details
2.1 Create dt-admin-access-role
Deploy Viven's bootstrap role template:
This role is used by Viven engineers to provision the Digital Twin stack. After provisioning, it is used only by Viven on-call engineers for critical and high-severity issue resolution.
2.2 Share kickoff inputs with Viven
| Required detail | Example |
|---|---|
| Company name + preferred domain | Acme Inc, acmeinc.com |
| AWS account ID | 123456789012 |
| Deployment region | us-west-2 |
| Bootstrap/admin role ARN | arn:aws:iam::123456789012:role/dt-admin-access-role |
With this information, Viven can start infrastructure deployment and typically complete it within a few days.
3. Set up ACM certificates and domain details
Create two ACM certificates:
- Regional certificate in your deployment region (used by ALB)
- Global certificate in
us-east-1(used by CloudFront)
For both certificates, use:
*.<your_domain>
Share with Viven:
- Regional certificate ARN
us-east-1certificate ARN- Primary domain/subdomain strategy (for example
digitaltwin.<your_domain>)
After go-live, if you need to rotate or replace certificates, follow the customer-facing AWS Certificate Rotation Playbook (ALB + CloudFront) →.
4. Share network or policy constraints early
Before Viven starts provisioning, share any environment constraints such as:
- SCPs or explicit deny policies
- Egress filtering / proxy requirements (for example Zscaler)
- IP allowlisting controls
- Existing VPC usage requirements (if not using a Viven-provisioned VPC)
Early review avoids deployment delays during bootstrap and image pull steps.
5. Notify Viven to start the build
Once steps 1-4 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
Appendix
Core AWS services used by Digital Twin
| AWS Service | Purpose |
|---|---|
| Amazon CloudFront | Secure global edge distribution |
| AWS Elastic Kubernetes Service (EKS) | Runs core application and worker workloads |
| Amazon EC2 | Compute instances and Airflow runtime |
| Amazon Redshift | Application/access log analytics |
| Amazon RDS (Aurora) | User/configuration data store |
| Amazon Route 53 | DNS management |
| Elastic Load Balancing | Traffic distribution |
| Amazon ElastiCache | Low-latency caching layer |
| Amazon DynamoDB | Primary processed-document datastore |
| Amazon ECR | Container image registry |
| Amazon S3 | Raw docs, artifacts, and release payloads |
| AWS IAM | Identity and role management |
| AWS KMS | Encryption key management |
| Amazon SES | Email delivery |
| Amazon SQS | Background task queues |
| Amazon SNS | Pub/sub notifications |
| Amazon Kinesis | Log stream transport |
| AWS Secrets Manager | Secret storage |
| Amazon CloudWatch | Metrics, logs, alerting |
| Amazon OpenSearch Service | Lexical/vector retrieval index |
Logs and operational access
Application logs and configuration data stay in your AWS account. Viven support tooling uses controlled role-based access to diagnose incidents, verify deployments, and enable approved features.