Deploy a Private YugabyteDB Anywhere Universe on AWS with Terraform

Two recent YugabyteDB Tips used Private Service Endpoints to connect privately to YugabyteDB Aeon:

YugabyteDB Anywhere works differently.

With Aeon, YugabyteDB manages the database network and publishes a private endpoint service for your cloud account to consume.

With YugabyteDB Anywhere, you own the AWS account, VPC, subnets, route tables, security groups, and database nodes. The YBA Terraform provider registers that infrastructure with YBA and then creates and manages the YugabyteDB universe.

Engineering validation in progress: This tip is currently under review by YugabyteDB Engineering to validate the Terraform configuration, resource behavior, and recommended deployment approach. The content may be updated based on that review.

The architecture for this tip looks like this:

				
					                      Customer AWS Account

                  Existing Application VPC
                            |
                            | Private VPC routing
                            | TCP 5433
                            v
                 YugabyteDB Security Group
                            |
                            v
                 Existing Private Subnets
                  /          |          \
                 /           |           \
          us-east-1a    us-east-1b    us-east-1c
               |             |             |
               +-------------+-------------+
                             |
                             v
               Private YugabyteDB Universe
                    No public node IPs
                             ^
                             |
                  Managed by YugabyteDB
                       Anywhere
                             ^
                             |
                 Terraform YBA Provider
				
			
This is not an AWS PrivateLink deployment: YugabyteDB Anywhere does not create an Aeon-style managed Private Service Endpoint. Instead, the YugabyteDB nodes are deployed directly into your private AWS subnets, and applications reach those nodes using customer-managed private networking.

What Are We Creating?

This demo:

  • ● Registers an existing AWS VPC with YugabyteDB Anywhere
  • ● Registers three private AWS subnets
  • ● Uses an existing YugabyteDB node security group
  • ● Allows an application security group to connect to YSQL
  • ● Uses an IAM role attached to the YBA host
  • ● Creates a three-node, replication-factor-three universe
  • ● Distributes the nodes across three Availability Zones
  • ● Assigns no public IP addresses to the database nodes
  • ● Enables YSQL authentication
  • ● Enables node-to-node and client-to-node encryption
  • ● Disables YCQL for an YSQL-only deployment
  • ● Outputs the private IP addresses of the YugabyteDB nodes

The current Terraform provider includes the cloud-specific yba_aws_provider resource and the yba_universe resource. The older generic yba_cloud_provider resource is deprecated and is planned for removal in a future major provider release.

What This Demo Assumes

This tip starts with the following resources already available:

  • ● A working YugabyteDB Anywhere installation
  • ● An existing AWS VPC
  • ● Three private subnets
  • ● A YugabyteDB node security group
  • ● An application security group
  • ● Network connectivity between YBA and the private database subnets
  • ● An IAM role attached to the YBA host
  • ● A YBA API token

The example does not install YugabyteDB Anywhere or create the underlying VPC.

Separating the network foundation from the YBA provider and universe configuration keeps the example focused and prevents Terraform from accidentally deleting shared networking resources during a universe cleanup.

YBA Versus Aeon Private Connectivity

Capability YugabyteDB Aeon YugabyteDB Anywhere
Database network Managed by YugabyteDB Managed by the customer
Private connection AWS PrivateLink or Azure Private Link VPC routing, peering, Transit Gateway, VPN, or Direct Connect
Database nodes Operated by YugabyteDB Deployed in the customer AWS account
Terraform provider yugabyte/ybm yugabyte/yba
Primary Terraform resources ybm_private_service_endpoint yba_aws_provider and yba_universe

Prerequisites

You will need:

  • ● Terraform 1.5 or later
  • ● YugabyteDB Anywhere stable version 2024.2.0.0 or later
  • ● A YBA API token
  • ● AWS credentials for the standard AWS Terraform provider
  • ● An existing AWS VPC
  • ● Three private subnets in separate Availability Zones
  • ● A security group configured for the YugabyteDB nodes
  • ● An application security group
  • ● An IAM role attached to the YBA EC2 instance with permissions to provision and manage the required AWS resources

The YBA Terraform provider is currently marked Early Access. Its current v1.x provider requires YBA stable version 2024.2.0.0 or later, or an eligible preview version.

Prepare the AWS Networking

YugabyteDB Anywhere needs:

  • ● A VPC ID for each configured region
  • ● A security group ID for each region
  • ● A subnet ID for every Availability Zone used by the provider
  • ● Connectivity from the YBA control plane to the database nodes
  • ● Connectivity between all YugabyteDB nodes

When existing VPCs are supplied, the customer is responsible for routing, peering, security groups, and cross-region connectivity.

This example assumes that the YugabyteDB node security group already permits:

  • ●YBA management traffic
  • ● Node Agent traffic
  • ● Internode communication
  • ● Monitoring traffic
  • ● Access to backup and software repositories as required

The Terraform code adds only the application-facing YSQL rule.

Do not build the node security group with only port 5433: YSQL client access is only one part of the network configuration. YugabyteDB Anywhere and the YugabyteDB nodes also require management, monitoring, and internode communication.

Private Subnets Need an Egress Strategy

The universe nodes will not receive public IP addresses.

When the nodes require access to software packages, database release artifacts, or other external services, the private subnets need an outbound path such as a NAT gateway. YBA’s AWS provider documentation specifically notes that a NAT gateway or equivalent device is required when public IP assignment is disabled, unless the environment is prepared for an air-gapped installation.

This tip uses:

				
					air_gap_install = false
				
			

Therefore, the private subnets need the required outbound access.

Create the Terraform Configuration

Create a file named main.tf:

				
					terraform {
  required_version = ">= 1.5.0"

  required_providers {
    yba = {
      source  = "yugabyte/yba"
      version = "~> 1.0"
    }

    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

###############################################################################
# Variables
###############################################################################

variable "aws_region" {
  description = "AWS region where the private YugabyteDB universe is deployed."
  type        = string
  default     = "us-east-1"
}

variable "database_vpc_id" {
  description = "Existing VPC where YugabyteDB nodes will be deployed."
  type        = string
}

variable "yb_node_security_group_id" {
  description = "Existing security group attached to the YugabyteDB nodes."
  type        = string
}

variable "application_security_group_id" {
  description = "Security group attached to the application."
  type        = string
}

variable "availability_zones" {
  description = "Ordered list of Availability Zones and private subnets."
  type = list(object({
    code      = string
    subnet_id = string
  }))
}

variable "provider_name" {
  description = "Name of the AWS provider configuration in YBA."
  type        = string
  default     = "private-aws-provider"
}

variable "universe_name" {
  description = "Name of the YugabyteDB universe."
  type        = string
  default     = "private-aws-universe"
}

variable "instance_type" {
  description = "AWS EC2 instance type for the YugabyteDB nodes."
  type        = string
  default     = "m6i.4xlarge"
}

variable "ysql_password" {
  description = "Password for the YugabyteDB YSQL user."
  type        = string
  sensitive   = true
}

###############################################################################
# Providers
###############################################################################

provider "aws" {
  region = var.aws_region
}

provider "yba" {
  # The following values are supplied through environment variables:
  #
  # YBA_HOST
  # YBA_API_TOKEN
  # YBA_ENABLE_HTTPS
}

###############################################################################
# Allow the Application to Reach YSQL
###############################################################################

resource "aws_vpc_security_group_ingress_rule" "ysql_from_application" {
  security_group_id            = var.yb_node_security_group_id
  referenced_security_group_id = var.application_security_group_id

  description = "Allow YSQL connections from the application"
  ip_protocol = "tcp"
  from_port   = 5433
  to_port     = 5433
}

###############################################################################
# Register the Existing AWS Infrastructure with YBA
###############################################################################

resource "yba_aws_provider" "private" {
  name = var.provider_name

  # Use the IAM role attached to the YugabyteDB Anywhere EC2 instance.
  use_iam_instance_profile = true

  regions {
    code              = var.aws_region
    vpc_id            = var.database_vpc_id
    security_group_id = var.yb_node_security_group_id

    dynamic "zones" {
      for_each = var.availability_zones

      content {
        code   = zones.value.code
        subnet = zones.value.subnet_id
      }
    }
  }

  # Allow YBA to manage the default x86_64 image bundle.
  yba_managed_image_bundles {
    arch           = "x86_64"
    use_as_default = true
  }

  # The private subnets have NAT or equivalent outbound access.
  air_gap_install = false

  # Use AWS Time Sync through chrony.
  set_up_chrony = true

  timeouts {
    create = "30m"
    update = "30m"
    delete = "30m"
  }
}

###############################################################################
# Retrieve the Access Key Created or Managed by YBA
###############################################################################

data "yba_provider_key" "aws" {
  provider_id = yba_aws_provider.private.id
}

###############################################################################
# Select the Latest Stable YBDB Release Available in YBA
###############################################################################

data "yba_release_version" "stable" {
  track = "stable"

  depends_on = [
    yba_aws_provider.private
  ]
}

###############################################################################
# Create the Private YugabyteDB Universe
###############################################################################

resource "yba_universe" "private" {
  clusters {
    cluster_type = "PRIMARY"

    user_intent {
      universe_name = var.universe_name

      provider    = yba_aws_provider.private.id
      region_list = yba_aws_provider.private.regions[*].uuid

      num_nodes          = 3
      replication_factor = 3
      instance_type      = var.instance_type

      device_info {
        num_volumes = 1
        volume_size = 500
        storage_type = "GP3"
        disk_iops   = 3000
        throughput  = 125
      }

      yb_software_version = data.yba_release_version.stable.id
      access_key_code     = data.yba_provider_key.aws.id

      # Keep the database nodes private.
      assign_public_ip = false

      # Database APIs
      enable_ysql      = true
      enable_ysql_auth = true
      ysql_password    = var.ysql_password

      enable_ycql      = false
      enable_ycql_auth = false

      # Encryption in transit
      enable_node_to_node_encrypt   = true
      enable_client_to_node_encrypt = true

      use_time_sync = true
      use_systemd   = true

      instance_tags = {
        Environment = "demo"
        ManagedBy   = "Terraform"
        Network     = "private"
      }
    }
  }

  communication_ports {}

  delete_options {
    delete_backups = false
    delete_certs   = false
    force_delete   = false
  }

  timeouts {
    create = "120m"
    update = "120m"
    delete = "45m"
  }

  depends_on = [
    aws_vpc_security_group_ingress_rule.ysql_from_application
  ]
}

###############################################################################
# Outputs
###############################################################################

output "yba_aws_provider_id" {
  description = "UUID of the AWS provider registered with YBA."
  value       = yba_aws_provider.private.id
}

output "yba_universe_id" {
  description = "UUID of the private YugabyteDB universe."
  value       = yba_universe.private.id
}

output "yba_universe_name" {
  description = "Name of the YugabyteDB universe."
  value       = var.universe_name
}

output "yb_software_version" {
  description = "YBDB release selected for the universe."
  value       = data.yba_release_version.stable.id
}

output "private_node_ips" {
  description = "Private IP addresses of the YugabyteDB nodes."

  value = [
    for node in yba_universe.private.node_details_set :
    node.cloud_info[0].private_ip
  ]
}

output "public_node_ips" {
  description = "Public IP addresses, which should be empty."

  value = [
    for node in yba_universe.private.node_details_set :
    node.cloud_info[0].public_ip
  ]
}
				
			

The order of the Availability Zone entries is intentional.

The current provider documentation notes that YBA may return Availability Zones in a different order than the original Terraform configuration. Because the nested zone block is order-sensitive, this can occasionally produce a cosmetic plan diff. After the first apply, the configuration can be reordered to match the order returned by YBA.

Authenticate with YugabyteDB Anywhere

Export the YBA hostname:

				
					export YBA_HOST="yba.example.internal:443"
				
			

Export the YBA API token:

				
					export YBA_API_TOKEN="<your-yba-api-token>"
				
			

Enable HTTPS:

				
					export YBA_ENABLE_HTTPS="true"
				
			

The provider also supports legacy YB_-prefixed environment variables, but the current provider documentation recommends the YBA_ names for new configurations.

Supply the YSQL Password

Do not place the password directly in terraform.tfvars.

Export it as a Terraform environment variable:

				
					export TF_VAR_ysql_password="<your-ysql-password>"
				
			

Terraform automatically maps that value to:

				
					variable "ysql_password"
				
			

Protect the Terraform State

The YSQL password is marked sensitive, which prevents Terraform from displaying it in normal CLI output.

However, the password is still stored in Terraform state. The provider documentation also notes that AWS access keys, secret keys, private SSH keys, and database passwords can be stored in state when those fields are used.

Sensitive does not mean encrypted: The Terraform sensitive attribute hides values from normal output, but it does not encrypt the Terraform state. Use an encrypted remote backend and tightly restrict access to state files and snapshots.

Why Use an IAM Instance Profile?

The provider configuration contains:

				
					use_iam_instance_profile = true
				
			

This tells YBA to use the IAM role attached to the YugabyteDB Anywhere host instead of storing AWS access keys in the provider configuration.

The IAM role must grant YBA sufficient permissions to create and manage EC2 instances, networking interfaces, volumes, key pairs, and related AWS resources. This option is available when the YBA host runs on AWS. Reference: Create cloud provider configuration.

When YBA is not running on AWS, replace the IAM setting with credentials:

				
					resource "yba_aws_provider" "private" {
  name = var.provider_name

  access_key_id     = var.aws_access_key_id
  secret_access_key = var.aws_secret_access_key

  # Remaining configuration...
}
				
			

Remember that those credentials will be stored in Terraform state.

Initialize Terraform

Run:

				
					terraform init
				
			

For an existing Terraform project that used an older provider version:

				
					terraform init -upgrade
				
			

Confirm the providers:

				
					terraform providers
				
			

Expected providers include:

				
					provider[registry.terraform.io/yugabyte/yba]
provider[registry.terraform.io/hashicorp/aws]
				
			

Format and Validate the Configuration

Format the files:

				
					terraform fmt
				
			

Validate the configuration:

				
					terraform validate
				
			

Expected result:

				
					Success! The configuration is valid.
				
			

Review the Terraform Plan

Create a saved plan:

				
					terraform plan -out=tfplan
				
			

The plan should include:

				
					aws_vpc_security_group_ingress_rule.ysql_from_application
yba_aws_provider.private
yba_universe.private
				
			

The two data sources will also be evaluated:

				
					data.yba_provider_key.aws
data.yba_release_version.stable
				
			

Check that the universe plan contains:

				
					assign_public_ip = false
				
			

Also confirm:

				
					num_nodes          = 3
replication_factor = 3
				
			

A Note About Selecting the Latest Stable Release

This demo uses:

				
					data "yba_release_version" "stable" {
  track = "stable"
}
				
			

That selects the latest stable YBDB release available in the connected YBA installation.

This is convenient for a disposable demo, but it can be dangerous for a long-lived production configuration. When a newer stable release becomes available, a future Terraform plan may detect a change to yb_software_version and initiate a database software upgrade.

Changing yb_software_version triggers the provider’s YBA upgrade workflow. Current provider behavior pauses an upgrade in the pre-finalize state by default unless the upgrade is explicitly finalized.

For production, pin a specific release:

				
					variable "yb_software_version" {
  description = "Exact YBDB release already available in YBA."
  type        = string
}

data "yba_release_version" "selected" {
  version = var.yb_software_version
}
				
			

Then use:

				
					yb_software_version = data.yba_release_version.selected.id
				
			
Do not let a data source silently define your production upgrade policy: Selecting the latest stable release is useful for a demo. For production, pin an exact tested release and change it through a reviewed upgrade process.

Apply the Configuration

Apply the saved plan:

				
					terraform apply tfplan
				
			

YBA will:

  • 1. Validate the AWS provider configuration.
  • 2. Register the VPC, security group, zones, and subnets.
  • 3. Select or create the required image and access-key configuration.
  • 4. Provision three EC2 instances.
  • 5. Install YugabyteDB.
  • 6. Configure the universe.
  • 7. Enable authentication and encryption.
  • 8. Return the universe and node information to Terraform.

Universe creation can take considerably longer than ordinary Terraform resource creation. The timeouts block increases the create timeout to two hours.

The provider documentation notes that a Terraform timeout stops Terraform from waiting, but does not necessarily cancel the YBA task. Check the task in YBA before starting another apply.

Display the Results

Show all outputs:

				
					terraform output
				
			

Example:

				
					private_node_ips = [
  "10.20.1.14",
  "10.20.2.27",
  "10.20.3.19",
]

public_node_ips = [
  "",
  "",
  "",
]

yb_software_version = "2026.1.0.0-bXX"

yba_aws_provider_id = "11111111-2222-3333-4444-555555555555"

yba_universe_id = "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"

yba_universe_name = "private-aws-universe"
				
			

The actual release, addresses, and UUIDs will differ.

Verify That the Nodes Are Private

Display the private IP addresses:

				
					terraform output private_node_ips
				
			

Display the public IP addresses:

				
					terraform output public_node_ips
				
			

The public addresses should be empty.

You can also inspect the EC2 instances in AWS:

				
					aws ec2 describe-instances \
  --filters \
    "Name=tag:universe-name,Values=private-aws-universe" \
  --query \
    'Reservations[].Instances[].{
      Instance:InstanceId,
      AvailabilityZone:Placement.AvailabilityZone,
      PrivateIP:PrivateIpAddress,
      PublicIP:PublicIpAddress,
      Subnet:SubnetId,
      State:State.Name
    }' \
  --output table
				
			

The exact instance tag names can vary depending on the YBA and provider configuration. When the filter does not return results, locate one node in the AWS console and inspect its tags before adjusting the command.

Verify the Three-Zone Placement

Show the node details stored by Terraform:

				
					terraform show
				
			

Search for:

				
					node_details_set
				
			

Each node should show a different Availability Zone:

				
					us-east-1a
us-east-1b
us-east-1c
				
			

The YBA provider can distribute nodes automatically when a region contains multiple zones. For exact placement, the cloud_list block can explicitly assign a node count to each Availability Zone.

An explicit placement configuration would look like this:

				
					clusters {
  cluster_type = "PRIMARY"

  user_intent {
    universe_name      = var.universe_name
    provider           = yba_aws_provider.private.id
    region_list        = yba_aws_provider.private.regions[*].uuid
    num_nodes          = 3
    replication_factor = 3
    instance_type      = var.instance_type

    device_info {
      num_volumes = 1
      volume_size = 500
      storage_type = "GP3"
      disk_iops   = 3000
      throughput  = 125
    }

    yb_software_version = data.yba_release_version.stable.id
    access_key_code     = data.yba_provider_key.aws.id

    assign_public_ip = false
    enable_ysql      = true
  }

  cloud_list {
    code = "aws"
    uuid = yba_aws_provider.private.id

    region_list {
      code = "us-east-1"

      az_list {
        code      = "us-east-1a"
        num_nodes = 1
      }

      az_list {
        code      = "us-east-1b"
        num_nodes = 1
      }

      az_list {
        code      = "us-east-1c"
        num_nodes = 1
      }
    }
  }
}
				
			

When using cloud_list, keep num_nodes equal to the sum of the per-zone node counts to avoid plan drift.

Test the YSQL Port

Choose one private node IP:

				
					nc -vz "${YB_HOST}" 5433
				
			

Expected result:

				
					Connection to 10.20.1.14 5433 port [tcp/*] succeeded!
				
			

This test must run from a host with private network access to the database VPC.

Connect with ysqlsh

Because client-to-node encryption is enabled, obtain the appropriate universe root certificate from YBA.

Then connect:

				
					YB_HOST=$(terraform output -json private_node_ips | jq -r '.[0]')

PGPASSWORD="${TF_VAR_ysql_password}" \
PGSSLMODE=require \
PGSSLROOTCERT=./root.crt \
ysqlsh \
  -h "${YB_HOST}" \
  -p 5433 \
  -U yugabyte \
  -d yugabyte
				
			

Verify the database:

				
					SELECT version();
				
			

Show the connected server:

				
					SELECT inet_server_addr(),
       inet_server_port();
				
			

Use Private DNS Instead of Hard-Coded IP Addresses

Applications should not normally hard-code one database node IP.

Options include:

  • ● YugabyteDB smart drivers with multiple private node addresses
  • ● Private Route 53 records
  • ● An internal DNS name maintained by automation
  • ● An internal load balancer when a smart driver is unavailable and the architecture requires one

YBA can integrate with Amazon Route 53, but YugabyteDB generally recommends smart client drivers when available because they understand the distributed database topology.

Example JDBC connection string:

				
					jdbc:yugabytedb://yb-1.internal.example.com:5433,yb-2.internal.example.com:5433,yb-3.internal.example.com:5433/yugabyte?load-balance=true
				
			

What If the Application Is in Another VPC?

The example security group rule references an application security group:

				
					referenced_security_group_id = var.application_security_group_id
				
			

That is a good fit when the application and database networking support security-group references.

When the application runs in another VPC, you must first provide private routing between the VPCs.

Common options include:

Topology Typical Network Option
Application and database in one VPC Local VPC routing
Two VPCs with a simple relationship VPC peering
Many application and database VPCs AWS Transit Gateway
On-premises application AWS Direct Connect or VPN

YBA must also be able to reach every database node. When YBA runs in a separate VPC, that VPC must participate in the private routing design, and the YugabyteDB node security group must permit the required YBA traffic.

Optional VPC Peering Example

For two non-overlapping VPCs in the same AWS account and region:

				
					variable "application_vpc_id" {
  type = string
}

variable "application_vpc_cidr" {
  type = string
}

variable "database_vpc_cidr" {
  type = string
}

variable "application_route_table_id" {
  type = string
}

variable "database_route_table_id" {
  type = string
}

resource "aws_vpc_peering_connection" "application_to_database" {
  vpc_id      = var.application_vpc_id
  peer_vpc_id = var.database_vpc_id
  auto_accept = true

  tags = {
    Name = "application-to-yugabyte"
  }
}

resource "aws_route" "application_to_database" {
  route_table_id            = var.application_route_table_id
  destination_cidr_block    = var.database_vpc_cidr
  vpc_peering_connection_id = aws_vpc_peering_connection.application_to_database.id
}

resource "aws_route" "database_to_application" {
  route_table_id            = var.database_route_table_id
  destination_cidr_block    = var.application_vpc_cidr
  vpc_peering_connection_id = aws_vpc_peering_connection.application_to_database.id
}

resource "aws_vpc_security_group_ingress_rule" "ysql_from_application_vpc" {
  security_group_id = var.yb_node_security_group_id

  description = "Allow YSQL from the application VPC"
  ip_protocol = "tcp"
  from_port   = 5433
  to_port     = 5433
  cidr_ipv4   = var.application_vpc_cidr
}
				
			

Both VPC route tables need reciprocal routes, and the VPC CIDR ranges must not overlap.

Multi-Region Universes

For a multi-region YBA universe, add multiple regions blocks to the yba_aws_provider resource.

Each region needs:

  • ● A VPC ID
  • ● A YugabyteDB node security group
  • ● One or more Availability Zones
  • ● A private subnet for each configured zone
  • ● Private connectivity to every other database region
  • ● Private connectivity from YBA

YugabyteDB’s AWS provider documentation recommends full private connectivity between regional VPCs. With direct VPC peering, this can require an N-by-N mesh and reciprocal routes for every regional CIDR.

For larger network topologies, Transit Gateway may be easier to operate than a large peering mesh.

Important Immutable Settings

Several universe settings cannot currently be changed through Terraform after creation, including:

  • ● Universe name
  • ● Cloud provider
  • ● Access key code
  • ● Whether YSQL or YCQL is enabled
  • ● Whether YSQL or YCQL authentication is enabled
  • ● Database passwords
  • ● Public-IP assignment
  • ● Satic-IP assignment
  • ● IPv6 assignment
  • ● Root certificate identifiers

Changing these values requires recreating the universe or managing the change through another supported workflow.

Avoid Mixing Terraform and Manual Changes

A universe managed by Terraform can still be changed through:

  • ● The YBA UI
  • ● The YBA API
  • ● The yba CLI
  • ● Another Terraform state

Those out-of-band changes can create drift.

Run:

				
					terraform plan
				
			

before every apply.

For CI/CD pipelines:

				
					terraform plan \
  -detailed-exitcode \
  -out=tfplan
				
			

The exit codes are:

				
					0 = No changes
1 = Terraform error
2 = Changes detected
				
			

Treat a result of 2 as a change requiring review rather than automatically applying it.

Destroy the Universe

Review the destroy plan:

				
					terraform plan -destroy
				
			

Destroy the resources:

				
					terraform destroy
				
			

Terraform will remove:

  • ● The YugabyteDB universe
  • ● The YBA AWS provider configuration
  • ● The application-facing YSQL security group rule

Terraform will not remove:

  • ● The existing VPC
  • ● The existing private subnets
  • ● The existing node security group
  • ● The existing application security group
  • ● The YBA installation

Those resources were supplied through variables rather than created in this configuration.

The universe resource supports delete options controlling whether YBA-managed backups and certificates are also removed. This demo retains them by setting both deletion options to false.

Final Takeaway

Private networking with YugabyteDB Anywhere is customer managed. Use the AWS Terraform provider to create or reference the VPC, private subnets, routes, and security groups. Use yba_aws_provider to register that infrastructure with YugabyteDB Anywhere. Then use yba_universe with assign_public_ip = false to deploy YugabyteDB nodes directly into private AWS subnets.

Reference Documentation

Have Fun!

I like catching early-morning movies on weekends to avoid the crowds. Yesterday, I saw Evil Dead Burn at 8:05 a.m. It felt a little strange... until one other guy walked into the theater and said, β€œThank goodness I’m not the only weirdo seeing an Evil Dead movie at 8 o’clock in the morning.” πŸ˜‚