VAST on Cloud Requirements for AWS

Introduction

This document assumes the reader is familiar with the VAST platform and AWS cloud and is intended for cloud architects, DevOps engineers, and infrastructure teams involved in the planning and execution of a VAST on Cloud installation in AWS.

It outlines the prerequisites for deploying and validating VAST on Cloud in AWS, providing guidance on preparing the cloud environment for a successful deployment. This includes configuring the network and setting the required roles/permissions. To keep these documents shorter, we will link other supporting documents where appropriate. T

VAST on Cloud clusters in AWS are created with Polaris, our cloud-based control plane and life-cycle management service.

The Polaris service consists of three primary components:

1. Polaris Cloud Service
   A cloud-based control plane that manages configuration, state, and day 2 operations for VAST clusters.

2. vastcloud CLI / SDK
   A command-line interface used to perform cluster lifecycle operations such as create, delete, and list (the focus of this document).

3. Polaris Agent
   A lightweight agent installed on VAST cluster nodes that establishes an outbound, NAT’d SSL connection to the Polaris service. This agent is responsible for securely transmitting telemetry and exchanging tokens required for ongoing management and orchestration.

This guide assumes the Polaris Cloud Service has been subscribed to and a Tenant/User provisioned. If this hasn’t been done, please refer to this guide [link]

Enterprise Governance & Cloud Architecture

Deploying infrastructure into a tightly controlled private subnet requires careful planning. The security, networking, and access configurations detailed in this guide may appear complex, but they reflect standard, industry-accepted design patterns for deploying an enterprise-grade IaaS solution under Zero Trust governance. We have documented the granular IAM permissions, firewall tags, and routing options explicitly so your Cloud Architecture and InfoSec teams can facilitate a secure deployment without compromising corporate security postures.

VAST understands the complexities of operating in regulated or policy-driven environments. Our tools and documentation are built with flexibility in mind, and we are prepared to adapt our deployment process to align with your organization’s specific requirements.

Should any policy-related issues arise, they are typically part of standard governance practices - not blockers. Our team is experienced in collaborating with cloud and security teams to ensure a smooth and compliant deployment.

Required: Dedicated Landing Zone in your AWS Account.

Dedicated Landing Zone in your AWS Account - IaaS Resources Required for VAST Cluster

IaaS Resources Created by the Installer:

• Networking

  • ENIs with multiple private IPs each (1/per VM).

• Logging

  • CloudWatch log group.

• Placement

  • Placement group (partition strategy).

• Compute

  • local.failure_domains × ENode Launch Templates.

  • local.failure_domains × ENode AutoScalingGroups.

  • local.vms_count × VMS Launch Templates.

  • local.vms_count × VMS AutoScalingGroups (fixed size = 1).

• Disks

  • Each instance (ENode/VMS) has 2 EBS volumes (1000GB + 50GB).

• Timing

  • Sleep resource to enforce delay after ASG creation.

• Virtual Machines:

  • The VAST cluster on AWS is deployed in an Ebox configuration with a dedicated node for the VMS (num_nodes+1) VMs.

Required Resources in the Target AWS Account

Before deploying the VAST on Cloud Platform, the following resources must already exist or be provisioned within the target AWS Account.

Note: VAST does not create or modify core resources in the AWS account during deployment.  VPCs,  subnets, Security Groups, etc. must be prepared in advance.

Networking:

The VAST cluster is installed in a private subnet but does require access to resources outside of the subnet/VPC during the installation.

Enabling access can be done in a few ways depending on your security and governance policies. In many mature cloud environments, access to the services needed is already enabled as a standard part of VPC and subnet configuration, but in a new Project they will need to be enabled.

NOTE: After configuring the network but before attempting to deploy a cluster, you should run vastcloud cluster preflight. (See Appendix B)

Security Group Setup:

Required Network Ports (Detailed list)

Network port requirements for the VAST cluster are grouped into three distinct use cases:

• Protocol & Access Ports (Ingress): These well-known IP ports are used for standard storage protocols, REST API access, and SSH management. They must be open for inbound traffic (ingress) from end-users, administrators, and any client applications (such as Spark, Kafka, or Trino) that need to consume cluster resources.

• Internal Cluster Ports (Local Only): These ports are only required for internal communication and orchestration between the cluster nodes. They only require local routing within the subnet and should not be exposed outside the cluster itself.

• Replication Ports (Ingress & Egress): These ports handle data replication and must be open for both inbound and outbound traffic at the cluster level. Crucially, if you are replicating data globally, you must ensure these ports are also explicitly allowed through all intermediate border routers and firewalls bridging your on-premises data center and your cloud network.

While detailed instructions for configuring firewall rules for AWS are beyond the scope of this document, we strongly recommend adhering to the principle of least privilege when applying firewall rules to your VAST cluster.

For VAST clustered storage deployments on AWS, a Recommended Best-Known Method (BKM) is to separate internal cluster communication from external client and service traffic by layering multiple security groups on each node's network interface (ENI).

The official AWS term for this is Security Group Referencing. It allows you to use a Security Group ID as a source or destination in its own rules (or in rules of other groups).

Benefit: This separation isolates "Data Plane" traffic from "Cluster Plane" traffic, simplifying audits and allowing for more restrictive access controls on client-facing interfaces.

Security Group Configuration Best Practices

1. Inter-Cluster (East–West) Security Group

A dedicated security group used to handle the high-volume, low-latency internal communication between VAST nodes (CNODEs and DNODEs).

• Inbound Traffic:    

  • Source: The Security Group ID of this group (e.g., sg-12345678)

  • Protocols/Ports: All Traffic / All Ports

  • Description: Self-referencing rule for node-to-node communication.

• Outbound Traffic:    

  • Destination: The Security Group ID of this group (e.g., sg-12345678)

  • Protocols/Ports: All Traffic / All Ports

  • Description: Self-referencing rule restricting external egress from this interface.

2. Client & Data Services (North–South) Security Group

A separate security group applied cumulatively to manage traffic entering or leaving the cluster from external networks and clients.

• Inbound Traffic:    

  • Source: Client CIDRs, Admin CIDRs, or Peer Security Groups

  • Protocols/Ports: Storage Protocols (NFS, SMB, S3), Admin Access (HTTPS, SSH), and Replication (Ports 49001/49002)

  • Description: Manages external data access, management UI, and cross-cluster replication.

• Outbound Traffic:    

  • Destination: Infrastructure Services and VAST Support Endpoints

  • Protocols/Ports: Identity Services (AD/LDAP), Core Infrastructure (DNS, NTP), and Support Uplink (HTTPS)

  • Description: Allows the cluster to connect to essential corporate services and remote monitoring.

VPC:

• Shared/Peered VPCs are supported for client access

Subnet:

VAST Cluster IP Subnet Prerequisites

• CRITICAL CONSTRAINT: Every VAST cluster requires its own dedicated subnet. Clusters cannot share subnets with any other resources.

• Standard Recommendation: Provide a /24 private subnet (252 usable IPs) per cluster.

• Minimum IP Calculation: If a /24 is not permitted, calculate the absolute minimum usable IPs required using N (Total Nodes) and V (VIPs per Node):

  • Total = N + 5 +2(N * V)

    • 2(N * V) accounts for both the Protocol and Replication pools.

  • Minimum allowable subnet mask - for single node - /26

Subnet CIDR Recommendations:

In the case where CIDR blocks are not assigned by the customer’s Network Operations Team.

Use RFC 1918 blocks:

• 10.0.0.0/8(Large)

• 172.16.0.0/12 (Medium - often used for "Lab" or "Dev" environments)

• 192.168.0.0/16 (Small - common in home/small office, high risk of conflict with VPN users)

Network  – Enabling Outbound Internet 0.0.0.0/0

NAT GW or Equivalent

• Purpose: Enable external access for VMs on private subnets. Because some AWS services are on public endpoints, they are enabled by a NAT GW as well.

• It is a simple and secure service but often prohibited in environments with strict governance or who route all external traffic through their own routers.

• If you are restricted from using use a NAT GW you will need to enable the Instance Metadata Service and add routes and whitelist the VAST public endpoints for, Polaris, Call Home and Uplink to your Internet Gateways.

• VAST cluster nodes use AWS Route53 for name resolution.

Instance Metadata Service

Local endpoint provided by AWS for every instance to retrieve instance metadata (such as IAM role credentials, instance ID, etc.).

• URL: http://169.254.169.254

• Connectivity Requirement: Ensure that the host firewall or iptables configurations on the instance do not block access to this IP address.

AWS S3 Gateway

The endpoint required to facilitate data transfer and object storage communication with AWS S3.

• Endpoint: https://s3.us-east-1.amazonaws.com

• Connectivity Options:    

  • Option 1: S3 Gateway VPC Endpoint (Recommended)        

    • Creates a private route within your VPC directly to S3.

    • Avoids the use of an Internet Gateway (IGW) or NAT Gateway.

    • Automatically updates the route tables of designated subnets with the com.amazonaws.us-east-1.s3 endpoint.

  • Option 2: Internet Access via IGW/NAT        

    • Requires traffic to pass through an Internet Gateway or NAT Gateway.

    • Security groups must explicitly allow outbound HTTPS (Port 443) traffic

Recommended Best Practices

Architectural and operational guidelines to ensure secure and verified connectivity.

• Architecture Guidelines:    

  • Use VPC Endpoints for both S3 and CloudFormation if you want to establish private connectivity and reduce exposure to the public internet.

  • Ensure your security groups explicitly allow outbound HTTPS traffic (Port 443) for services that must utilize the internet.

  • Update route tables for private subnets to properly point to either a NAT Gateway or the designated VPC endpoints.

• Connectivity Verification:    

  • Test and validate communication paths from the instance using the following command strings:        

    • curl -v http://169.254.169.254/latest/meta-data/

    • curl -v https://cloudformation.us-east-1.amazonaws.com

    • curl -v https://s3.us-east-1.amazonaws.com

Network Connectivity – Global Namespace/Replication

To use Global Namespace or snapshot replication, you will need a dedicated link with routing between your Data Center hosting the origin VAST cluster and AWS VPC networks utilizing one of the following:

• Performance POC: AWS Direct Connect (Dedicated or Partner) is required for consistent high-throughput replication.

• Functional POC: AWS Site-to-Site VPN (HA VPN recommended) is acceptable for initial testing and lower bandwidth requirements.

• Firewall Exceptions (Replication): Open the following ports on both the on-premises firewall and the AWS Security Group:

  • TCP 49001: VAST Replication Service.

  • TCP 49002: VAST Replication Service.

• Routing: Verify bidirectional routing between on-prem storage nodes and the AWS VPC Subnet CIDR.

• MTU Settings: Confirm MTU consistency (typically 1460 or 1500) across the VPN/Interconnect to avoid packet fragmentation, which can significantly degrade replication performance.

Network Connectivity – VAST Internet Gateway Whitelist.

IAM Authentication & Access Models

To deploy a VAST Data cluster in AWS using our Polaris deployment engine, specific administrative and resource-level permissions are required within your AWS account. These permissions authorize the user account utilized by the vastcloud utility to execute Terraform to cleanly create and destroy the VAST Data Cluster infrastructure on demand.

The vastcloud CLI includes a built-in validation mechanism to verify your active security posture before provisioning infrastructure. It is highly recommended to execute the following command in your terminal before attempting a deployment to validate your chosen option:

vastcloud cluster --check-permissions

To accommodate different enterprise compliance frameworks, select one of the three permission models below to configure the AWS Identity (User or Role) executing the deployment.

Option 1: Administrator Access (Easiest, but Least Secure)

The simplest way to ensure vastcloud runs without API permission errors is to grant the IAM User or Role full administrative privileges at the AWS Account level.

• Assigned Policy: arn:aws:iam::aws:policy/AdministratorAccess

• Use Case: Accelerated proof-of-concept (PoC) setups, short-lived evaluation sandboxes, or isolated personal lab environments.

⚠️ Security Warning: While it may be appropriate for POCs in fenced off Accounts, this configuration breaks the principle of least privilege. It grants unrestricted, destructive capabilities across all AWS services within the target Account and should never be used in production environments.

Option 2: Predefined AWS Job-Function Policies (Balanced Approach)

1. Attach Predefined AWS Policies: Assign the following standard AWS-managed job function policies to the IAM User or Role hosting the deployment runner:

   • AmazonEC2FullAccess (To provision lab servers, volumes, and network segments)

   • AutoScalingFullAccess (To manage dynamic lab clustering rules)

   • PowerUserAccess (To handle data plane operations like storage bucket data, application configuration secrets, and tracking logs)

2. Apply the Custom IAM Guardrail Addendum: Standard AWS managed policies explicitly block the creation of security roles to prevent unauthorized security escalations. Because our deployment engine must build and attach isolated, low-privilege runtime security roles directly to the temporary lab servers, your security team must attach the custom policy addendum provided below.

3. Enterprise Guardrail Enforced: To adhere strictly to corporate least-privilege standards, this custom addendum restricts the deployment runner so that it can only create, delete, or pass roles that are strictly locked inside the /voc/* path namespace. It cannot modify or touch any existing corporate infrastructure identities.

For DevSecOps Reference: Technical Custom IAM Policy Appendix

Version: "2012-10-17"
Statement:
  - Sid: PathScopedIAMManagement
    Effect: Allow
    Action:
      - iam:CreateRole
      - iam:DeleteRole
      - iam:GetRole
      - iam:GetRolePolicy
      - iam:PutRolePolicy
      - iam:DeleteRolePolicy
      - iam:TagRole
      - iam:UntagRole
      - iam:PassRole
      - iam:AttachRolePolicy
      - iam:DetachRolePolicy
      - iam:ListAttachedRolePolicies
      - iam:ListInstanceProfilesForRole
    Resource: "arn:aws:iam::*:role/voc/*"

  - Sid: PathScopedPolicyManagement
    Effect: Allow
    Action:
      - iam:CreatePolicy
      - iam:DeletePolicy
      - iam:GetPolicy
      - iam:GetPolicyVersion
      - iam:CreatePolicyVersion
      - iam:DeletePolicyVersion
      - iam:SetDefaultPolicyVersion
      - iam:ListPolicyVersions
      - iam:TagPolicy
      - iam:UntagPolicy
    Resource: "arn:aws:iam::*:policy/voc/*"

  - Sid: PathScopedInstanceProfileManagement
    Effect: Allow
    Action:
      - iam:CreateInstanceProfile
      - iam:DeleteInstanceProfile
      - iam:GetInstanceProfile
      - iam:AddRoleToInstanceProfile
      - iam:RemoveRoleFromInstanceProfile
      - iam:TagInstanceProfile
      - iam:UntagInstanceProfile
    Resource: "arn:aws:iam::*:instance-profile/voc/*"

  - Sid: ConditionalCloudWatchAttachment
    Effect: Allow
    Action:
      - iam:AttachRolePolicy
      - iam:DetachRolePolicy
    Resource: "arn:aws:iam::*:role/voc/*"
    Condition:
      ArnEquals:
        iam:PolicyARN: "arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy"

Option 3: Path-Scoped Custom Policy / Least Privilege (Recommended for Production)

For strict enterprise compliance, a dedicated Custom IAM Policy should be compiled containing only the fine-grained micro-permissions required by the underlying Terraform state machine.

To satisfy corporate least-privilege standards, this configuration implements a strict Enterprise Security Guardrail. The attached custom policy heavily restricts identity mutation using path-scoped constraints - locking IAM, Policy, and Instance Profile creation exclusively to the /voc/* path namespace. This guarantees that the automation framework can create, modify, and pass the temporary lab runner roles it needs without the ability to touch, view, or alter any existing corporate production fabrics or infrastructure identities.

(Note: The full detailed micro-permission YAML mapping for this custom policy can be found in Appendix A for reference by your DevSecOps / Cloud Security team).

Appendix A: Detailed IAM Policy (YAML Format)

For environments requiring explicit, custom inline configurations rather than AWS Managed Policies, apply this comprehensive, least-privilege policy directly to the Terraform execution identity.

Before you begin -- replace these placeholders:

Version: "2012-10-17"
Statement:
  - Sid: STSValidation
    Effect: Allow
    Action:
      - sts:GetCallerIdentity
    Resource: "*"

  - Sid: EC2Read
    Effect: Allow
    Action:
      - ec2:DescribeRegions
      - ec2:DescribeAvailabilityZones
      - ec2:DescribeVpcs
      - ec2:DescribeSubnets
      - ec2:DescribeSecurityGroups
      - ec2:DescribeKeyPairs
      - ec2:DescribeInstances
      - ec2:DescribeInstanceStatus
      - ec2:DescribeInstanceTypes
      - ec2:DescribeInstanceAttribute
      - ec2:DescribeInstanceCreditSpecifications
      - ec2:DescribeNetworkInterfaces
      - ec2:DescribeTags
      - ec2:DescribeAddresses
      - ec2:DescribeImages
      - ec2:DescribeLaunchTemplates
      - ec2:DescribeLaunchTemplateVersions
      - ec2:DescribePlacementGroups
      - ec2:DescribeVolumes
      - ec2:DescribeManagedPrefixLists
      - ec2:GetManagedPrefixListEntries
      - ec2:GetConsoleOutput
    Resource: "*"

  - Sid: EC2Write
    Effect: Allow
    Action:
      - ec2:RunInstances
      - ec2:TerminateInstances
      - ec2:ImportKeyPair
      - ec2:CreateSecurityGroup
      - ec2:AuthorizeSecurityGroupIngress
      - ec2:DeleteSecurityGroup
      - ec2:CreateTags
      - ec2:CreateNetworkInterface
      - ec2:DeleteNetworkInterface
      - ec2:AssignPrivateIpAddresses
      - ec2:UnassignPrivateIpAddresses
      - ec2:AttachNetworkInterface
      - ec2:DetachNetworkInterface
      - ec2:AllocateAddress
      - ec2:AssociateAddress
      - ec2:DisassociateAddress
      - ec2:ReleaseAddress
      - ec2:CreateVolume
      - ec2:DeleteVolume
      - ec2:AttachVolume
      - ec2:DetachVolume
      - ec2:CreateLaunchTemplate
      - ec2:DeleteLaunchTemplate
      - ec2:ModifyLaunchTemplate
      - ec2:CreateLaunchTemplateVersion
      - ec2:CreatePlacementGroup
      - ec2:DeletePlacementGroup
      - ec2:CreateManagedPrefixList
      - ec2:DeleteManagedPrefixList
      - ec2:ModifyManagedPrefixList
    Resource: "*"

  - Sid: AutoScaling
    Effect: Allow
    Action:
      - autoscaling:CreateAutoScalingGroup
      - autoscaling:UpdateAutoScalingGroup
      - autoscaling:DeleteAutoScalingGroup
      - autoscaling:DescribeAutoScalingGroups
      - autoscaling:DescribeAutoScalingInstances
      - autoscaling:DescribeScalingActivities
      - autoscaling:SetDesiredCapacity
      - autoscaling:TerminateInstanceInAutoScalingGroup
      - autoscaling:DescribeTags
      - autoscaling:CreateOrUpdateTags
      - autoscaling:SuspendProcesses
    Resource: "*"

  - Sid: S3ClusterAndState
    Effect: Allow
    Action:
      - s3:CreateBucket
      - s3:DeleteBucket
      - s3:ListBucket
      - s3:GetObject
      - s3:PutObject
      - s3:DeleteObject
      - s3:PutBucketTagging
      - s3:GetLifecycleConfiguration
      - s3:PutLifecycleConfiguration
    Resource:
      - "arn:aws:s3:::vast-cluster-*"
      - "arn:aws:s3:::vast-cluster-*/*"
      - "arn:aws:s3:::vastcloud-*"
      - "arn:aws:s3:::vastcloud-*/*"

  - Sid: S3ListBuckets
    Effect: Allow
    Action:
      - s3:ListAllMyBuckets
    Resource: "*"

  - Sid: IAMReadOnly
    Effect: Allow
    Action:
      - iam:ListRoles
      - iam:ListRolePolicies
      - iam:ListPolicies
    Resource: "*"

  - Sid: IAMManageRoles
    Effect: Allow
    Action:
      - iam:CreateRole
      - iam:DeleteRole
      - iam:GetRole
      - iam:GetRolePolicy
      - iam:PutRolePolicy
      - iam:DeleteRolePolicy
      - iam:TagRole
      - iam:UntagRole
      - iam:PassRole
      - iam:AttachRolePolicy
      - iam:DetachRolePolicy
      - iam:ListAttachedRolePolicies
      - iam:ListInstanceProfilesForRole
    Resource: "arn:aws:iam::{ACCOUNT_ID}:role/voc/*"

  - Sid: IAMManagePolicies
    Effect: Allow
    Action:
      - iam:CreatePolicy
      - iam:DeletePolicy
      - iam:GetPolicy
      - iam:GetPolicyVersion
      - iam:CreatePolicyVersion
      - iam:DeletePolicyVersion
      - iam:SetDefaultPolicyVersion
      - iam:ListPolicyVersions
      - iam:TagPolicy
      - iam:UntagPolicy
    Resource: "arn:aws:iam::{ACCOUNT_ID}:policy/voc/*"

  - Sid: IAMManageInstanceProfiles
    Effect: Allow
    Action:
      - iam:CreateInstanceProfile
      - iam:DeleteInstanceProfile
      - iam:GetInstanceProfile
      - iam:AddRoleToInstanceProfile
      - iam:RemoveRoleFromInstanceProfile
      - iam:TagInstanceProfile
      - iam:UntagInstanceProfile
    Resource: "arn:aws:iam::{ACCOUNT_ID}:instance-profile/voc/*"

  - Sid: IAMAttachCloudWatchPolicy
    Effect: Allow
    Action:
      - iam:AttachRolePolicy
      - iam:DetachRolePolicy
    Resource: "arn:aws:iam::{ACCOUNT_ID}:role/voc/*"
    Condition:
      ArnEquals:
        iam:PolicyARN: "arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy"

  - Sid: SecretsManagerRead
    Effect: Allow
    Action:
      - secretsmanager:ListSecrets
      - secretsmanager:DescribeSecret
      - secretsmanager:GetResourcePolicy
    Resource: "*"

  - Sid: SecretsManagerWrite
    Effect: Allow
    Action:
      - secretsmanager:CreateSecret
      - secretsmanager:DeleteSecret
      - secretsmanager:PutSecretValue
      - secretsmanager:GetSecretValue
      - secretsmanager:TagResource
      - secretsmanager:UntagResource
    Resource: "arn:aws:secretsmanager:{REGION}:{ACCOUNT_ID}:secret:*"

  - Sid: CloudWatchLogsRead
    Effect: Allow
    Action:
      - logs:DescribeLogGroups
      - logs:DescribeLogStreams
      - logs:ListTagsForResource
    Resource: "*"

  - Sid: CloudWatchLogsWrite
    Effect: Allow
    Action:
      - logs:CreateLogGroup
      - logs:CreateLogStream
      - logs:DeleteLogGroup
      - logs:DeleteLogStream
      - logs:PutLogEvents
      - logs:PutRetentionPolicy
      - logs:TagResource
      - logs:UntagResource
    Resource: "arn:aws:logs:{REGION}:{ACCOUNT_ID}:log-group:*"

  - Sid: ECR
    Effect: Allow
    Action:
      - ecr:GetAuthorizationToken
    Resource: "*"

Appendix B: Run the Pre-Flight Checker

vastcloud cluster preflight is a single interactive wizard that validates Polaris login, cloud credentials, looks up the Polaris deployment, checks IAM permissions, required tools, runs a Terraform network pre-checker, and optional resource-name conflict checks before you run cluster create.

For a complete run, you will need to have a user in a Polaris tenant and be authenticated to the cloud where you are going to deploy. It can be run without authentication to the Polaris service, but several checks will fail; however, the core cloud checks for IAM permissions, quotas, and network configurations will run and provide valid feedback. So if you are still waiting for your Polaris user login, you can still download the vastcloud binary and run the preflight checker tests, with the caveat that some phases will fail.

For a complete how-to for AWS, please see this document.