YugabyteDB 2025.2.8.0

In the AWS Marketplace listing, choose Continue to Subscribe and then Continue to Configuration. Pick YugabyteDB 2025.2.8.0 on Ubuntu 24.04 as the software version and select your Region. Then choose Launch through EC2.

Choose m5.large or larger. YugabyteDB needs at least 8 GiB of memory, and you should give it more for larger working sets. Choose your key pair and a security group as described above.

The AMI brings two volumes: the root volume and a 20 GiB data volume (/dev/sdf) for /var/lib/yugabyte. Make the data volume as large as your data needs at launch.

To launch with the AWS CLI instead, replace the values in angle brackets. This example grows the data volume to 100 GiB:

aws ec2 run-instances --region <region> --image-id <ami-id-from-the-listing> \
  --instance-type m5.large --key-name <your-key-pair> \
  --security-group-ids <your-security-group> --subnet-id <your-subnet> \
  --block-device-mappings 'DeviceName=/dev/sdf,Ebs={VolumeSize=100,VolumeType=gp3}' \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=yugabytedb}]'

If you make the data volume larger at launch, grow the file system once after first boot with sudo resize2fs "$(findmnt -no SOURCE /var/lib/yugabyte)". First boot takes about a minute after the instance is running.

The AMI itself requires IMDSv2, so an instance launched from it without --metadata-options still refuses IMDSv1. Verify this with:

aws ec2 describe-images --image-ids <ami-id-from-the-listing> \
  --query 'Images[0].[Description,ImdsSupport]' --output text

YugabyteDB 2025.2.8.0 on Ubuntu 24.04 by sac v2.0

Version SSH user

YugabyteDB 2025.2.8.0 on Ubuntu 24.04 ubuntu

ssh -i <your-key.pem> ubuntu@<public-ip>

The first-boot service, the master and the tablet server should all be active:

systemctl is-active yugabytedb-firstboot.service yb-master.service yb-tserver.service

active active active

Every YugabyteDB port listens on the loopback address, and from the network only SSH is reachable:

sudo ss -Htln

LISTEN 0 128 127.0.0.1:12000 0.0.0.0:* LISTEN 0 4096 127.0.0.53%lo:53 0.0.0.0:* LISTEN 0 128 127.0.0.1:7000 0.0.0.0:* LISTEN 0 128 127.0.0.1:7100 0.0.0.0:* LISTEN 0 4096 0.0.0.0:22 0.0.0.0:* LISTEN 0 4096 127.0.0.54:53 0.0.0.0:* LISTEN 0 644 127.0.0.1:5433 0.0.0.0:* LISTEN 0 128 127.0.0.1:9042 0.0.0.0:* LISTEN 0 128 127.0.0.1:9000 0.0.0.0:* LISTEN 0 128 127.0.0.1:9100 0.0.0.0:* LISTEN 0 128 127.0.0.1:13000 0.0.0.0:* LISTEN 0 4096 [::]:22 [::]:*

5433 is YSQL, 9042 is YCQL, 7100 and 9100 are the RPC ports of the master and the tablet server, 7000 and 9000 are their web consoles, and 13000 and 12000 are the YSQL and YCQL metrics consoles. The port 53 lines are the local DNS resolver of Ubuntu, which is also loopback only. The same sockets appear below with the process that owns each one:

sudo ss -Htlnp | awk '{print $4, $6}' | sed 's/,pid=[0-9]*,fd=[0-9]*//g' | sort -V

0.0.0.0:22 users:(("sshd"),("systemd")) 127.0.0.1:5433 users:(("postgres")) 127.0.0.1:7000 users:(("yb-master")) 127.0.0.1:7100 users:(("yb-master")) 127.0.0.1:9000 users:(("yb-tserver")) 127.0.0.1:9042 users:(("yb-tserver")) 127.0.0.1:9100 users:(("yb-tserver")) 127.0.0.1:12000 users:(("yb-tserver")) 127.0.0.1:13000 users:(("postgres")) 127.0.0.53%lo:53 users:(("systemd-resolve")) 127.0.0.54:53 users:(("systemd-resolve")) [::]:22 users:(("sshd"),("systemd"))

yb-admin connects over TLS with the certificates of the instance and shows the master as the leader of the cluster:

sudo -u yugabyte /opt/yugabyte/bin/yb-admin --master_addresses 127.0.0.1:7100 --certs_dir_name /etc/yugabyte/tls list_all_masters

Master UUID RPC Host/Port State Role Broadcast Host/Port 31f106e98b66484285455adf751ee3e9 127.0.0.1:7100 ALIVE LEADER 127.0.0.1:7100

The health check of the master reports no dead nodes and no under-replicated tablets:

curl -s http://127.0.0.1:7000/api/v1/health-check; echo

{"dead_nodes":[],"most_recent_uptime":13,"under_replicated_tablets":[]}

Your connection details are in /root/yugabytedb-credentials.txt. Show them with:

sudo grep -E '^YUGABYTEDB_(VERSION|YSQL_HOST|YSQL_PORT|YSQL_USER|YSQL_DATABASE|YCQL_PORT|YCQL_USER|TLS_CA)=' /root/yugabytedb-credentials.txt

YUGABYTEDB_VERSION=2025.2.8.0-b60 YUGABYTEDB_YSQL_HOST=127.0.0.1 YUGABYTEDB_YSQL_PORT=5433 YUGABYTEDB_YSQL_USER=yugabyte YUGABYTEDB_YSQL_DATABASE=yugabyte YUGABYTEDB_YCQL_PORT=9042 YUGABYTEDB_YCQL_USER=cassandra YUGABYTEDB_TLS_CA=/etc/yugabyte/tls/ca.crt

To show a password itself, for example for a client on your own computer, run:

sudo grep -E '^YUGABYTEDB_(YSQL|YCQL)_PASSWORD=' /root/yugabytedb-credentials.txt

yugabyte is the YSQL superuser and cassandra the YCQL superuser. YUGABYTEDB_TLS_CA_SHA256 in the same file is the SHA-256 fingerprint of the certificate authority of this instance. Clients trust the database by its certificate /etc/yugabyte/tls/ca.crt.

Everything that identifies this instance was made after it booted, because the AMI ships none of it. Compare the boot time with the certificate authority, the server certificate and the credentials file:

uptime -s sudo ls -l --time-style=+'%F %T' /etc/yugabyte/tls/ca.crt /etc/yugabyte/tls/ca.key \
  /etc/yugabyte/tls/node.127.0.0.1.crt /root/yugabytedb-credentials.txt | awk '{print $1, $3":"$4, $6, $7, $8}'

2026-11-09 14:41:23 -rw-r--r-- root:yugabyte 2026-11-09 14:42:03 /etc/yugabyte/tls/ca.crt -rw------- root:root 2026-11-09 14:42:03 /etc/yugabyte/tls/ca.key -rw-r--r-- root:yugabyte 2026-11-09 14:42:03 /etc/yugabyte/tls/node.127.0.0.1.crt -rw------- root:root 2026-11-09 14:43:10 /root/yugabytedb-credentials.txt

yb-ysqlsh runs ysqlsh (YugabyteDB's psql) as yugabyte against 127.0.0.1:5433. It verifies the server certificate and hands over the password in a temporary root-only file:

sudo yb-ysqlsh -c 'SELECT version();'
sudo yb-ysqlsh -c 'SELECT ssl, version, cipher FROM pg_stat_ssl WHERE pid = pg_backend_pid();'

version -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- PostgreSQL 15.12-YB-2025.2.8.0-b0 on x86_64-pc-linux-gnu, compiled by clang version 19.1.0 (https://github.com/yugabyte/llvm-project.git a2a6b655e14e7fa1fcf1011a6cb29cb8575249c0), 64-bit (1 row) ssl | version | cipher -----+---------+------------------------ t | TLSv1.3 | TLS_AES_256_GCM_SHA384 (1 row)

Create a table split into three tablets, load rows and run an aggregation with a window function. Run:

sudo yb-ysqlsh -c "CREATE TABLE IF NOT EXISTS orders (id bigint PRIMARY KEY, region text NOT NULL, amount numeric(10,2) NOT NULL) SPLIT INTO 3 TABLETS;"
sudo yb-ysqlsh -c "INSERT INTO orders SELECT g, (ARRAY['EMEA','APAC','AMER'])[1 + g % 3], round((g * 7.31)::numeric % 500, 2) FROM generate_series(1, 3000) AS g ON CONFLICT (id) DO NOTHING;"
sudo yb-ysqlsh -c "SELECT region, count(*) AS orders, sum(amount) AS revenue, rank() OVER (ORDER BY sum(amount) DESC) AS rank FROM orders GROUP BY region ORDER BY rank;"
sudo yb-ysqlsh -c "SELECT num_tablets, num_hash_key_columns FROM yb_table_properties('orders'::regclass);"

CREATE TABLE INSERT 0 3000 region | orders | revenue | rank --------+--------+-----------+------ APAC | 1000 | 250345.00 | 1 AMER | 1000 | 248655.00 | 2 EMEA | 1000 | 247465.00 | 3 (3 rows) num_tablets | num_hash_key_columns -------------+---------------------- 3 | 1 (1 row)

Run sudo yb-ysqlsh with no options for an interactive session (\q quits). For applications, create a dedicated role rather than using yugabyte. For example, run CREATE ROLE app LOGIN PASSWORD '<password>';, followed by the GRANT statements that your application needs.

yb-ycqlsh runs ycqlsh as cassandra against 127.0.0.1:9042 over verified TLS. It hands over the password in a temporary root-only file:

sudo yb-ycqlsh -e "CREATE KEYSPACE IF NOT EXISTS shop; CREATE TABLE IF NOT EXISTS shop.carts (user_id int, item text, qty int, PRIMARY KEY ((user_id), item)); INSERT INTO shop.carts (user_id, item, qty) VALUES (1, 'keyboard', 1); INSERT INTO shop.carts (user_id, item, qty) VALUES (1, 'mouse', 2);"
sudo yb-ycqlsh -e "SELECT * FROM shop.carts WHERE user_id = 1;"

user_id | item | qty ---------+----------+----- 1 | keyboard | 1 1 | mouse | 2 (2 rows)

For applications, create a dedicated role with CREATE ROLE app WITH PASSWORD = '<password>' AND LOGIN = true;, then GRANT it the keyspaces it needs.

sudo yb-ysqlsh -c "DROP TABLE IF EXISTS orders;"
sudo yb-ycqlsh -e "DROP TABLE IF EXISTS shop.carts; DROP KEYSPACE IF EXISTS shop;"

DROP TABLE

Every port listens on 127.0.0.1. From your computer, forward the ports you need over SSH:

ssh -i <your-key.pem> -N -L 5433:127.0.0.1:5433 -L 9042:127.0.0.1:9042 -L 7000:127.0.0.1:7000 -L 9000:127.0.0.1:9000 ubuntu@<public-ip>

Copy the certificate authority of the instance to your computer once (scp -i <your-key.pem> ubuntu@<public-ip>:/etc/yugabyte/tls/ca.crt yugabytedb-ca.crt). Then connect with any PostgreSQL client or driver, or with cqlsh/ycqlsh and the Cassandra drivers:

psql "host=127.0.0.1 port=5433 user=yugabyte dbname=yugabyte sslmode=verify-full sslrootcert=yugabytedb-ca.crt" SSL_CERTFILE=yugabytedb-ca.crt ycqlsh --ssl -u cassandra 127.0.0.1 9042

Enter the passwords from Step 4 when prompted. The certificate names 127.0.0.1, localhost and the private and public addresses of the instance, so sslmode=verify-full works through the tunnel.

The web consoles are the master console of YugabyteDB at http://127.0.0.1:7000/ (cluster overview, tablet servers, tables and tablets) and the tablet server console at http://127.0.0.1:9000/.

The web consoles (ports 7000, 9000, 12000 and 13000) have no login of their own, so anyone with a shell on the instance can read them. That is why they listen on localhost only. Open them through the SSH tunnel above. Never expose ports 7000, 9000, 12000 or 13000 to a network, and give shell access to the instance only to people you would trust with the database.

The Tablet Servers page lists the tablet server of the instance, 127.0.0.1:9000, as ALIVE, with its tablet peers and leaders.

The Tables page shows each YSQL and YCQL table with its on-disk size. Here it shows the orders table from Step 5 (database yugabyte) and the carts table from Step 6 (keyspace shop).

If applications in your VPC must connect without SSH, bind the client ports to all interfaces. TLS and password authentication stay enforced. YSQL accepts only TLS connections with SCRAM passwords and refuses plaintext, and YCQL refuses unencrypted connections. Edit /etc/yugabyte/tserver.conf:

sudo sed -i 's#^--pgsql_proxy_bind_address=127.0.0.1:5433$#--pgsql_proxy_bind_address=0.0.0.0:5433#' /etc/yugabyte/tserver.conf
sudo sed -i 's#^--cql_proxy_bind_address=127.0.0.1:9042$#--cql_proxy_bind_address=0.0.0.0:9042#' /etc/yugabyte/tserver.conf
sudo systemctl restart yb-tserver.service

Then allow TCP 5433 (and 9042 for YCQL) in the security group of the instance from your own network only, and never from 0.0.0.0/0:

aws ec2 authorize-security-group-ingress --group-id <your-security-group> \
  --protocol tcp --port 5433 --cidr <your-cidr>

Clients connect to the private (or public) IP with the certificate authority from Step 8, for example psql "host=<private-ip> port=5433 user=yugabyte dbname=yugabyte sslmode=verify-full sslrootcert=yugabytedb-ca.crt". A public IP that is not an Elastic IP changes when the instance is stopped and started, and the certificate names only the addresses that the instance had at first boot. Use sslmode=verify-ca if you connect by a name that the certificate does not carry.

Keep the RPC ports (7100, 9100) and the consoles on localhost unless you are building a multi-node cluster. To close access again, put the two lines back to 127.0.0.1, restart yb-tserver and remove the security group rule.

YugabyteDB and its first-boot service cannot reach the instance metadata service:

systemctl show -p IPAddressDeny yb-master.service yb-tserver.service yugabytedb-firstboot.service

IPAddressDeny=169.254.169.254/32 168.63.129.16/32 fd00:ec2::254/128 IPAddressDeny=169.254.169.254/32 168.63.129.16/32 fd00:ec2::254/128 IPAddressDeny=169.254.169.254/32 168.63.129.16/32 fd00:ec2::254/128

Without a session token, the metadata service refuses even your own login shell (the AMI requires IMDSv2):

curl -s -o /dev/null -w '%{http_code}\n' http://169.254.169.254/latest/meta-data/instance-id

401

First boot runs in a private network namespace with only its own loopback. Neither server starts before first boot has finished and the data volume is set up:

systemctl show -p PrivateNetwork yugabytedb-firstboot.service
systemctl cat yb-master.service | grep '^ExecStartPre='

PrivateNetwork=yes ExecStartPre=/usr/bin/test -f /var/lib/sac/data/yugabytedb-firstboot.done ExecStartPre=/usr/bin/test -f /var/lib/yugabyte/.sac-bootstrapped

The effective settings of the tablet server are: authentication on for both APIs, TLS between clients and servers and between the servers, unencrypted connections refused, call home off, and the client ports on localhost:

curl -s 'http://127.0.0.1:9000/varz?raw=1' | grep -E '^--(callhome_enabled|ysql_enable_auth|use_cassandra_authentication|use_client_to_server_encryption|use_node_to_node_encryption|allow_insecure_connections|pgsql_proxy_bind_address|cql_proxy_bind_address)='

--allow_insecure_connections=false --callhome_enabled=false --cql_proxy_bind_address=127.0.0.1:9042 --pgsql_proxy_bind_address=127.0.0.1:5433 --use_cassandra_authentication=true --use_client_to_server_encryption=true --use_node_to_node_encryption=true --ysql_enable_auth=true

A connection without TLS is refused on both APIs:

/opt/yugabyte/bin/ysqlsh -w "host=127.0.0.1 port=5433 user=yugabyte dbname=yugabyte sslmode=disable" -c 'SELECT 1' 2>&1 | grep -o 'FATAL:.*' /opt/yugabyte/bin/ycqlsh 127.0.0.1 9042 -e 'SELECT now() FROM system.local' 2>&1 | grep -o 'Connection error.*servers'

FATAL: pg_hba.conf rejects connection for host "127.0.0.1", user "yugabyte", database "yugabyte", no encryption Connection error: ('Unable to connect to any servers

YugabyteDB runs unprivileged:

ps -o user:9=,comm= -u yugabyte | sort | uniq -c sudo grep -E '^(CapEff|NoNewPrivs)' /proc/$(systemctl show -p MainPID --value yb-tserver.service)/status

5 yugabyte postgres 1 yugabyte yb-master 1 yugabyte yb-tserver CapEff: 0000000000000000 NoNewPrivs: 1

Both servers run in a systemd sandbox. systemd-analyze security scores their exposure from 0 (best) to 10:

for u in yb-master yb-tserver; do systemd-analyze security --no-pager $u.service | grep -o 'Overall exposure level for .*: [0-9.]* [A-Z]*'; done

Overall exposure level for yb-master.service: 1.6 OK Overall exposure level for yb-tserver.service: 1.6 OK

The image has its own round-trip check. The per-instance passwords work over verified TLS and an analytic query returns exact results. The check refuses yugabyte/yugabyte, cassandra/cassandra, the password-less postgres role, blank, common and random passwords, and plaintext connections. It also checks that every port is loopback only:

sudo setsid -w timeout 120 /usr/local/sbin/yugabytedb-roundtrip.sh < /dev/null 2>&1 | tail -1

OK-yugabytedb-roundtrip

setsid runs the check without your terminal, so none of its refusal probes can stop at an interactive password prompt.

For YSQL, \password sends the new password to the server already hashed. Sign in, set the password, then update the credentials file so that yb-ysqlsh keeps working:

sudo yb-ysqlsh yugabyte=# \password yugabyte yugabyte=# \q
sudo sed -i 's/^YUGABYTEDB_YSQL_PASSWORD=.*/YUGABYTEDB_YSQL_PASSWORD=<new-password>/' /root/yugabytedb-credentials.txt

For YCQL, sign in with sudo yb-ycqlsh, run ALTER ROLE cassandra WITH PASSWORD = '<new-password>'; and update YUGABYTEDB_YCQL_PASSWORD the same way.

• Back up with EBS snapshots of the data volume (consistent when you stop yb-tserver and yb-master first), with a logical YSQL dump, or with YugabyteDB's own distributed snapshots. This image does not include the YB Controller backup daemon (see "What this image leaves out"); yb-admin and ysql_dump are the backup tools. To dump the schema and data of the yugabyte database to a root-only file, run sudo yb-ysql-dump > /root/yugabyte-$(date +%F).sql. To take a distributed snapshot, which is kept on the data volume, run:

sudo -u yugabyte /opt/yugabyte/bin/yb-admin --master_addresses 127.0.0.1:7100 --certs_dir_name /etc/yugabyte/tls create_database_snapshot ysql.yugabyte
sudo -u yugabyte /opt/yugabyte/bin/yb-admin --master_addresses 127.0.0.1:7100 --certs_dir_name /etc/yugabyte/tls list_snapshots

Started snapshot creation: 556415f7-8c4c-40cb-afaf-8fc4a05b2e64 Snapshot UUID State Creation Time 556415f7-8c4c-40cb-afaf-8fc4a05b2e64 COMPLETE 2026-11-09 14:43:56.628721 No snapshot restorations

The data volume is separate from the root volume:

df -h --output=source,size,target / /var/lib/yugabyte

Filesystem Size Mounted on /dev/root 11G / /dev/nvme1n1 20G /var/lib/yugabyte

• Memory: YugabyteDB sizes its caches from the memory of the instance at start (--use_memory_defaults_optimized_for_ysql). Choose a larger instance type for larger working sets, and restart both services after resizing.
• Logs: Run sudo journalctl -u yb-tserver.service -n 50, or read the server logs in /var/lib/yugabyte/logs/master and /var/lib/yugabyte/logs/tserver.
• Configuration: The servers read their flags from /etc/yugabyte/master.conf and /etc/yugabyte/tserver.conf. Restart the service after a change. Keep --callhome_enabled=false, --allow_insecure_connections=false and the authentication flags as they are.
• Certificates: The key of the certificate authority, /etc/yugabyte/tls/ca.key, stays on the instance (root only) so you can sign certificates for more nodes. The servers use node.127.0.0.1.crt and node.127.0.0.1.key.
• Updates: Ubuntu security updates install automatically (systemctl is-enabled unattended-upgrades prints enabled, and /etc/apt/apt.conf.d/20auto-upgrades sets APT::Periodic::Unattended-Upgrade "1";). YugabyteDB is installed from the tarball of the vendor in /opt/yugabyte. Upgrade it deliberately by following the manual upgrade procedure of YugabyteDB after taking a snapshot of the data volume, and keep to the v2025.2 LTS series for long-term support.