SQL Server 2025 Express on Ubuntu 24.04

In the AWS Marketplace listing, choose Continue to Subscribe, then Continue to Configuration. Pick SQL Server 2025 Express on Ubuntu 24.04 as the software version and select your Region, then choose Launch through EC2.

Choose m5.large or larger, your key pair and a security group as described above. SQL Server needs at least 2 GB of memory.

Alternatively, launch with the AWS CLI. Replace the values in angle brackets:

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> \
  --metadata-options HttpTokens=required,HttpEndpoint=enabled \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=sql-server-express}]'

On a new instance, first boot takes about five minutes. Amazon EBS loads the AMI's blocks from its snapshot the first time they are read, and SQL Server's setup reads 1.4 GB of program files. Until first boot finishes, systemctl is-active mssql-firstboot reports activating and /root/mssql-credentials.txt holds a placeholder. Later boots start SQL Server in seconds.

Version SSH user

SQL Server 2025 Express on Ubuntu 24.04 ubuntu

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

The first-boot service and SQL Server both report active:

systemctl is-active mssql-firstboot mssql-server

active active

Check what is listening. SQL Server listens on the loopback address only. 1433 is the database port and 1431 is an internal SQL Server port. Only SSH listens on the network.

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

0.0.0.0:22 users:(("sshd"),("systemd")) 127.0.0.1:1431 users:(("sqlservr")) 127.0.0.1:1433 users:(("sqlservr")) 127.0.0.53%lo:53 users:(("systemd-resolve")) 127.0.0.54:53 users:(("systemd-resolve")) [::1]:1431 users:(("sqlservr")) [::]:22 users:(("sshd"),("systemd"))

The credentials file is readable only by root. List the setting names it holds:

sudo ls -l /root/mssql-credentials.txt
sudo grep -oE '^[A-Z_0-9]+=' /root/mssql-credentials.txt

-rw------- 1 root root 686 Oct 24 20:45 /root/mssql-credentials.txt SA_USER= SA_PASSWORD= <set-at-first-boot>= TLS_CERT= TLS_CERT_SHA256=

Read the whole file with sudo cat /root/mssql-credentials.txt and store the password in your password manager. It is unique to this instance.

Everything that identifies this instance was created after it booted. Compare the boot time with the credentials file, the TLS key and certificate and the master database. The AMI ships none of them:

uptime -s sudo ls -l --time-style=+'%F %T' /root/mssql-credentials.txt /etc/ssl/mssql/mssql.pem \
  /etc/ssl/mssql/mssql.key /var/opt/mssql/data/master.mdf | awk '{print $1, $3":"$4, $6, $7, $8}'

2026-11-09 14:19:11 -rw-r----- root:mssql 2026-11-09 14:19:37 /etc/ssl/mssql/mssql.key -rw-r--r-- root:mssql 2026-11-09 14:19:37 /etc/ssl/mssql/mssql.pem -rw------- root:root 2026-11-09 14:24:26 /root/mssql-credentials.txt -rw-rw---- mssql:mssql 2026-11-09 14:24:18 /var/opt/mssql/data/master.mdf

Never pass the password to sqlcmd with -P, because it would land in your shell history and the process list. sqlcmd reads it from the SQLCMDPASSWORD environment variable instead. Load it once per shell:

export SQLCMDPASSWORD="$(sudo awk -F= '/^SA_PASSWORD=/{print $2}' /root/mssql-credentials.txt)"

The blocks below repeat that line so that each one works on its own. sqlcmd is on the PATH of every login shell (/opt/mssql-tools18/bin); the blocks use the full path.

-C tells sqlcmd to trust the instance's self-signed certificate (Step 6 shows how to pin it instead).

export SQLCMDPASSWORD="$(sudo awk -F= '/^SA_PASSWORD=/{print $2}' /root/mssql-credentials.txt)" /opt/mssql-tools18/bin/sqlcmd -S 127.0.0.1 -U sa -C -Q "SET NOCOUNT ON; SELECT CAST(SERVERPROPERTY('Edition') AS nvarchar(40)) AS edition, CAST(SERVERPROPERTY('ProductVersion') AS nvarchar(20)) AS version, CAST(SERVERPROPERTY('ProductUpdateLevel') AS nvarchar(10)) AS cu"

edition version cu ---------------------------------------- -------------------- ---------- Express Edition (64-bit) 17.0.5035.5 CU10

A login that does not exist is refused:

export SQLCMDPASSWORD="$(sudo awk -F= '/^SA_PASSWORD=/{print $2}' /root/mssql-credentials.txt)" /opt/mssql-tools18/bin/sqlcmd -S 127.0.0.1 -U demo -C -Q "SELECT 1" 2>&1 | head -1

Sqlcmd: Error: Microsoft ODBC Driver 18 for SQL Server : Login failed for user 'demo'..

SQL Server forces encryption, so even a client that asks only for optional encryption (-No) gets an encrypted session:

export SQLCMDPASSWORD="$(sudo awk -F= '/^SA_PASSWORD=/{print $2}' /root/mssql-credentials.txt)" /opt/mssql-tools18/bin/sqlcmd -S 127.0.0.1 -U sa -C -No -Q "SET NOCOUNT ON; SELECT encrypt_option, protocol_type, auth_scheme FROM sys.dm_exec_connections WHERE session_id = @@SPID"

encrypt_option protocol_type auth_scheme ---------------------------------------- ---------------------------------------- ---------------------------------------- TRUE TSQL SQL

The certificate is this instance's own, named after its hostname:

openssl x509 -in /etc/ssl/mssql/mssql.pem -noout -subject -enddate -ext subjectAltName -fingerprint -sha256

subject=CN = ip-172-31-89-182 notAfter=Oct 21 20:43:52 2036 GMT X509v3 Subject Alternative Name: DNS:ip-172-31-89-182, DNS:localhost, IP Address:127.0.0.1 sha256 Fingerprint=38:62:0C:C0:83:02:0C:73:49:57:87:7B:57:0D:E5:B8:18:8C:B8:5B:17:91:F0:08:67:9A:82:D5:F5:DB:4F:54

The same fingerprint is in /root/mssql-credentials.txt as TLS_CERT_SHA256.

To verify the server instead of trusting it blindly, copy /etc/ssl/mssql/mssql.pem (the public certificate, never mssql.key) to your client and add it to the client's trusted certificates. In tools that support it, you can pin the fingerprint instead. Because the certificate names localhost and 127.0.0.1, verification also passes through the SSH tunnel in Step 8.

On the instance itself, sqlcmd can verify the server against its own certificate instead of trusting it with -C. Make the certificate the only trust anchor and name localhost as the host in the certificate (-F):

export SQLCMDPASSWORD="$(sudo awk -F= '/^SA_PASSWORD=/{print $2}' /root/mssql-credentials.txt)" SSL_CERT_FILE=/etc/ssl/mssql/mssql.pem /opt/mssql-tools18/bin/sqlcmd -S 127.0.0.1 -U sa -F localhost -h -1 -W \
  -Q "SET NOCOUNT ON; SELECT 'verified against this instance''s own certificate'"

verified against this instance's own certificate

Create a database, write a row, read it back and drop the database:

export SQLCMDPASSWORD="$(sudo awk -F= '/^SA_PASSWORD=/{print $2}' /root/mssql-credentials.txt)" /opt/mssql-tools18/bin/sqlcmd -S 127.0.0.1 -U sa -C -W -Q "SET NOCOUNT ON; CREATE DATABASE demo; EXEC('USE demo; CREATE TABLE dbo.notes (id INT IDENTITY PRIMARY KEY, body NVARCHAR(200) NOT NULL); INSERT INTO dbo.notes (body) VALUES (N''hello from SQL Server 2025 Express'');'); SELECT id, body FROM demo.dbo.notes; DROP DATABASE demo;"

id body -- ---- 1 hello from SQL Server 2025 Express

SQL Server 2025's native vector type, regular expressions and JSON functions work in Express. Try them in a database of your own (here demo, created and kept for this example):

export SQLCMDPASSWORD="$(sudo awk -F= '/^SA_PASSWORD=/{print $2}' /root/mssql-credentials.txt)" /opt/mssql-tools18/bin/sqlcmd -S 127.0.0.1 -U sa -C -W -Q "SET NOCOUNT ON; CREATE DATABASE demo;" /opt/mssql-tools18/bin/sqlcmd -S 127.0.0.1 -U sa -C -d demo -h -1 -W -Q "SET NOCOUNT ON; CREATE TABLE dbo.docs (id INT PRIMARY KEY, \
  title NVARCHAR(100), embedding VECTOR(3)); INSERT INTO dbo.docs VALUES \
  (1, N'EC2 launch guide', '[0.1,0.9,0.2]'), (2, N'SQL Server notes', '[0.8,0.1,0.3]'), \
  (3, N'Ubuntu tips', '[0.2,0.8,0.1]');" /opt/mssql-tools18/bin/sqlcmd -S 127.0.0.1 -U sa -C -d demo -h -1 -W -Q "SET NOCOUNT ON; SELECT TOP 2 id, title, \
  CAST(VECTOR_DISTANCE('cosine', embedding, CAST('[0.1,0.9,0.1]' AS VECTOR(3))) AS DECIMAL(6,4)) \
  AS dist FROM dbo.docs ORDER BY dist;" /opt/mssql-tools18/bin/sqlcmd -S 127.0.0.1 -U sa -C -d demo -h -1 -W -Q "SET NOCOUNT ON; SELECT id, title FROM dbo.docs \
  WHERE REGEXP_LIKE(title, '^(EC2|Ubuntu)'); SELECT JSON_OBJECT('id': id, 'title': title) \
  FROM dbo.docs WHERE id = 2;"

1 EC2 launch guide .0058 3 Ubuntu tips .0089 1 EC2 launch guide 3 Ubuntu tips {"id":2,"title":"SQL Server notes"}

Drop it when you are done: /opt/mssql-tools18/bin/sqlcmd -S 127.0.0.1 -U sa -C -Q "DROP DATABASE demo;".

For an application, create its own login and database instead of using sa. Run this in an interactive sqlcmd session (/opt/mssql-tools18/bin/sqlcmd -S 127.0.0.1 -U sa -C) and choose your own strong password:

CREATE DATABASE appdb; GO CREATE LOGIN appuser WITH PASSWORD = N'<a-strong-password>', CHECK_POLICY = ON; GO USE appdb; CREATE USER appuser FOR LOGIN appuser; ALTER ROLE db_owner ADD MEMBER appuser; GO

The safest way to use SQL Server Management Studio, Azure Data Studio, VS Code or an application on your workstation is an SSH tunnel. Port 1433 stays closed to the network. Open the tunnel:

ssh -i <your-key.pem> -N -L 1433:127.0.0.1:1433 ubuntu@<public-ip>

Then connect your client to 127.0.0.1,1433 with SQL Server authentication as sa, encryption Mandatory (or Strict), and either trust the server certificate or install mssql.pem as a trusted certificate (Step 6).

If applications on other hosts in your VPC must connect directly, open the listen address and restart SQL Server, then allow TCP 1433 in the security group from those hosts' CIDRs only, never from 0.0.0.0/0:

sudo /opt/mssql/bin/mssql-conf unset network.ipaddress
sudo systemctl restart mssql-server

Encryption stays forced. The certificate names the instance's hostname, localhost and 127.0.0.1. Clients that connect by another name must trust the certificate or use a certificate you issue for that name (mssql-conf set network.tlscert and network.tlskey, then restart).