Skip to main content

AWS Deployment FAQ

This FAQ answers common questions for customer-managed (BYOC) AWS deployments of Digital Twin.

1) Do you support AWS BYOC or customer-owned VPC deployments?​

Yes. Digital Twin can be deployed inside your AWS account and VPC, so your data remains in your cloud environment.

2) What should we provision before deployment starts?​

Most deployments require:

  • A dedicated AWS account
  • A supported AWS region
  • Required IAM roles/users for deployment
  • ACM certificates
  • DNS records (for example, Route 53 or your DNS provider)

Your Viven team will confirm the exact checklist for your environment.

3) What AWS IAM access is required?​

Viven needs provisioning access to set up the platform in your AWS account.
For operations, role-based access is used for monitoring and approved incident response.

4) Which AWS region should we use?​

Choose a supported AWS commercial region that aligns with your data residency, latency, and compliance requirements.
Before finalizing the region, confirm all required AWS services for your deployment are available there.
AWS GovCloud regions are not currently supported.

5) What VPC, subnet, and CIDR details are needed?​

You should be ready to provide:

  • VPC CIDR range
  • Private subnets for compute workloads
  • Database and cache subnet plans
  • Public/NAT subnet strategy (if applicable)
  • Any pod CIDR or custom networking requirements

This helps prevent IP exhaustion and networking conflicts.

6) How are application deployments performed after infrastructure setup?​

After infrastructure is ready, deployments follow a controlled release flow:

  1. Viven builds the release image and completes validation checks.
  2. The approved release is versioned for traceability.
  3. Deployment automation uses the cross-account role and permissions to access your AWS environment.
  4. The new release is rolled out to the target services.

7) How does Viven ensure only trusted releases are deployed?​

Viven uses a controlled release process so only approved software is eligible for deployment in your AWS environment. Viven uses AWS Signer to sign release images as part of this process.

Before rollout, deployment workflows run integrity checks on the release package.
If those checks fail, the deployment is blocked automatically.

8) How are logging and monitoring handled?​

Logs and runtime telemetry remain in your AWS account.
Monitoring typically uses CloudWatch, with optional integration into additional monitoring systems for alerting and support workflows.

9) How are vulnerabilities and container image scanning handled?​

Viven addresses application-level vulnerabilities and follows regular patching and image scanning practices.
Images are versioned for traceability, and customers can run additional scans in their own security workflows.

10) Can we use Azure OpenAI with an AWS deployment?​

Yes, if network connectivity and security controls allow access from AWS to your Azure OpenAI endpoint.
Required model deployments, endpoint configuration, and credentials must be set up in your secure secret management flow.

11) What network and security checks should we complete before deployment?​

Confirm the following early:

  • Outbound connectivity requirements
  • Firewall/proxy behavior
  • TLS/certificate requirements
  • DNS/domain readiness
  • Public endpoint allowlisting, if required
  • Any corporate security tooling that may affect SSL inspection or outbound traffic

12) How do we rotate AWS certificates after go-live (ALB and CloudFront)?​

Use the customer-facing AWS Certificate Rotation Playbook →.

It includes step-by-step instructions to:

  • Create/import replacement ACM certificates
  • Update the ALB HTTPS listener certificate in your deployment region
  • Update the CloudFront certificate in us-east-1
  • Validate and roll back safely if needed