Skip to content

Cloud Integrations

VOR Stream is designed to be deployed into a cloud environment and leverage cloud-specific features to provide a more robust and scalable solution. When deployed in supported cloud environments, VOR Stream can take advantage of compute resource management to optimize costs.

General Cloud Features

Key points about cloud compute host management:

  • Compute resources remain powered off by default to minimize costs
  • When a run is requested, VOR Stream automatically powers on the required compute resources
  • After processing completes, compute resources are automatically powered off
  • If the Midtier host is abruptly powered off, the compute resources will not be powered off until the Midtier host is powered back on
  • Compute resource state is tracked in Consul to maintain awareness of compute node availability
  • The VOR Stream Midtier node handles the registration and deregistration of compute resources with Consul, ensuring service discovery remains accurate even when compute resources are powered off

This allows you to maintain a pool of compute resources while only incurring costs when those resources are actively being used for processing.

Deployment Recommendations

The key recommendation for any cloud deployment is to separate compute services from other VOR Stream services. This separation enables cost optimization by allowing compute nodes to be powered down when not in use.

Compute Node Requirements

  • Deploy compute services on dedicated compute resources separate from other VOR Stream services (the SDK can still be deployed on compute resources)
  • These dedicated compute resources can be powered off when not processing runs
  • The VOR Stream Midtier will automatically manage the power state of compute resources
  • Compute resources should be launched with appropriate permissions to manage compute resources (see cloud-specific requirements below)
  • Compute resources should use on-demand pricing to ensure the fastest possible startup times

Shared Storage Requirements

When separating compute and midtier services, it's critical that all playpen directories are:

  • Mounted on both the midtier, compute, and SDK hosts
  • Mounted at identical paths across all hosts
  • Accessible with consistent permissions

For example, if a playpen directory is mounted at /data/playpen on the midtier host, it must also be mounted at /data/playpen on all compute hosts. This can be achieved using a shared filesystem like NFS.

AWS-Specific Requirements

IAM Permissions

The VOR Stream Midtier services requires IAM permissions to start and stop EC2 instances. Credentials will be sourced from the AWS SDK's default credential chain, which will search for credentials in the following order:

  1. Environment variables
  2. AWS credentials file
  3. EC2 instance profile (recommended)

The following is an example IAM policy that grants the necessary permissions.

Example JSON IAM Policy
{
   "Version": "2012-10-17",
   "Statement": [
      {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
               "ec2:StartInstances",
               "ec2:StopInstances"
            ],
            "Resource": "arn:aws:ec2:*:*:instance/*",
            "Condition": {
               "StringEquals": {
                  "ec2:ResourceTag/Environment": "Development" // (1)!
               }
            }
      },
      {
            "Sid": "VisualEditor1",
            "Effect": "Allow",
            "Action": [
               "ec2:DescribeInstances",
               "ec2:DescribeRegions",
               "ec2:DescribeSpotInstanceRequests",
               "ec2:DescribeInstanceStatus"
            ],
            "Resource": "*" // (2)!
      }
   ]
}
  1. This condition is an example of how you might use tags to control access to resources. In this case, we are restricting access to instances that have a tag of Environment with a value of Development.
  2. This statement grants permission to describe all instances, regions, spot instance requests, and instance statuses.
Example Terraform IAM EC2 Instance Manager Role
resource "aws_iam_role" "vor_midtier_instance_manager" {
  name = "vor-midtier-instance-manager"
  path = "/"

  assume_role_policy = data.aws_iam_policy_document.instance_assume_role_policy.json
}

data "aws_iam_policy_document" "instance_assume_role_policy" {
  statement {
    actions = ["sts:AssumeRole"]

    principals {
      type        = "Service"
      identifiers = ["ec2.amazonaws.com"]
    }
  }
}

resource "aws_iam_role_policy_attachments_exclusive" "vor_midtier_instance_manager" {
  role_name = aws_iam_role.vor_midtier_instance_manager.name
  policy_arns = [
     aws_iam_policy.vor_midtier_instance_manager.arn,
  ]
}

resource "aws_iam_policy" "vor_midtier_instance_manager" {
  name = "vor-midtier-instance-manager"

  policy = data.aws_iam_policy_document.vor_midtier_instance_manager.json
}

data "aws_iam_policy_document" "vor_midtier_instance_manager" {
  statement {
    actions = [
      "ec2:StartInstances",
      "ec2:StopInstances"
    ]
    resources = ["arn:aws:ec2:*:*:instance/*"]
    condition { # (1)!
      test     = "StringEquals"
      values   = ["Development"]
      variable = "ec2:ResourceTag/Environment"
    }
  }

  statement { # (2)!
    actions = [
      "ec2:DescribeInstances",
      "ec2:DescribeRegions",
      "ec2:DescribeSpotInstanceRequests",
      "ec2:DescribeInstanceStatus"
    ]
    resources = ["*"]
  }
}
  1. This condition is an example of how you might use tags to control access to resources. In this case, we are restricting access to instances that have a tag of Environment with a value of Development.
  2. This statement grants permission to describe all instances, regions, spot instance requests, and instance statuses.

Azure-Specific Requirements

Role Assignments

The VOR Stream Midtier service requires permissions to start and stop Azure VMs. These permissions can be granted through Azure RBAC (Role-Based Access Control). The following actions are required:

  • Microsoft.Compute/virtualMachines/start/action
  • Microsoft.Compute/virtualMachines/deallocate/action
  • Microsoft.Compute/virtualMachines/read

Credentials will be sourced from the Azure SDK's default credential chain, which will search for credentials in the following order:

  1. Environment variables
  2. Managed Identity (recommended)
  3. Azure CLI credentials

The following is an example of an Azure role definition that grants the necessary permissions.

Example Role JSON
{
    "id": "/subscriptions/a62b2bec-1abd-41e6-936c-aaf5d43a9b1d/providers/Microsoft.Authorization/roleDefinitions/bfb4166c-884a-861e-fdf9-b4aa0f37a6d1",
    "properties": {
        "roleName": "vor-midtier-start-stop-role",
        "description": "",
        "assignableScopes": [
            "/subscriptions/a62b2bec-1abd-41e6-936c-aaf5d43a9b1d"
        ],
        "permissions": [
            {
                "actions": [
                    "Microsoft.Compute/virtualMachines/start/action",
                    "Microsoft.Compute/virtualMachines/deallocate/action",
                    "Microsoft.Compute/virtualMachines/read"
                ],
                "notActions": [],
                "dataActions": [],
                "notDataActions": []
            }
        ]
    }
}
Example Terraform Role Definition and Assignment
resource "azurerm_role_definition" "vor_midtier_instance_manager" {
  name  = "vor-midtier-instance-manager"
  scope = "..."
  permissions {
    actions = [
      "Microsoft.Compute/virtualMachines/start/action",
      "Microsoft.Compute/virtualMachines/deallocate/action",
      "Microsoft.Compute/virtualMachines/read",
    ]
    not_actions      = []
    data_actions     = []
    not_data_actions = []
  }

  assignable_scopes = ["..."]
}

resource "azurerm_role_assignment" "vor_midtier_instance_manager" {
  scope              = "..."
  role_definition_id = azurerm_role_definition.vor_midtier_instance_manager.role_definition_resource_id
  principal_id       = "..."
}