SQL Server 2022 Standard

Search Azure Marketplace for SQL Server 2022 Standard, select the SecureAnyCloud offer and click Create.

On the Basics tab, choose your subscription, resource group and region, and name the VM. Choose Standard_D4s_v3 or larger, because SQL Server needs at least 2 GB of memory. Set the administrator account. Under Inbound port rules, allow SSH (22) only.

On the Disks tab, choose Standard SSD or Premium SSD. SQL Server data lives in /var/opt/mssql/data on the OS disk.

On the Networking tab, keep or select a network security group that allows SSH from your admin network. Click Review + create, then Create.

Accept the Marketplace terms once per subscription, then create the VM. Replace the values in angle brackets with your own.

az vm image terms accept --urn sac1647283583153:mssql-2022-standard-ubuntu-22-04:default:latest
az vm create \
  --resource-group <your-resource-group> \
  --name sql-std-01 \
  --image sac1647283583153:mssql-2022-standard-ubuntu-22-04:default:latest \
  --size Standard_D4s_v3 \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_rsa.pub \
  --nsg-rule SSH

First boot takes two to three minutes while SQL Server's setup creates the system databases. Until it finishes, systemctl is-active mssql-firstboot reports activating and /root/mssql-credentials.txt does not yet hold the real password. Later boots start SQL Server in seconds.

Connect to the VM over SSH:

ssh azureuser@<vm-public-ip>

Confirm that the first-boot service and SQL Server both report active:

systemctl is-active mssql-firstboot mssql-server

active active

Check what is listening. Port 1433 is the database port, open on every interface (IPv4 0.0.0.0 and the dual-stack *). Port 1431 is a SQL Server port used only on the VM. Port 1434 is the local dedicated administrator connection (DAC), the emergency connection a sysadmin can use from the VM itself when SQL Server stops responding. Both stay on the loopback address, and remote DAC is off.

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

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

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 1201 Oct 23 12:37 /root/mssql-credentials.txt SA_USER= SA_PASSWORD= <set-at-first-boot>= SQL_ENDPOINT_PRIVATE= SQL_EDITION= 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 VM.

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), and the blocks use the full path.

Run sqlcmd on the VM. The -C flag tells it to trust the VM's self-signed certificate. Step 6 shows how to verify the certificate 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, CAST(SERVERPROPERTY('EngineEdition') AS int) AS engine_edition"

edition version cu engine_edition ---------------------------------------- -------------------- ---------- -------------- Standard Edition (64-bit) 16.0.4305.5 CU27 2

An engine_edition of 2 is the Standard engine.

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

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 VM's own, named after its hostname (the VM name) and addresses. Inspect it with the command below. The sample output is from a different VM, so your names and fingerprint will differ.

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

subject=CN = mssql-std-2204-simA-10231152-264a62 notAfter=Oct 20 12:35:13 2036 GMT X509v3 Subject Alternative Name: DNS:mssql-std-2204-simA-10231152-264a62, DNS:localhost, IP Address:127.0.0.1, IP Address:10.0.0.12 sha256 Fingerprint=74:D2:6D:37:BC:F4:99:F1:4E:CD:FE:91:89:46:C6:AF:C9:FC:77:08:4C:92:DB:37:07:44:79:30:30:A1:1E:8B

The same fingerprint is in /root/mssql-credentials.txt as TLS_CERT_SHA256. To verify the server instead of trusting it blindly, make the certificate the client's trusted certificate and drop -C. A client without the certificate refuses the self-signed one. With it, full verification passes:

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 "$(hostname)" -h -1 -Q "SET NOCOUNT ON; SELECT N'verified: ' + CAST(SERVERPROPERTY('ServerName') AS nvarchar(64))"

verified: mssql-std-2204-simA-10231152-264a62

On your workstation, copy /etc/ssl/mssql/mssql.pem and add it to the client's trusted certificates. This is the public certificate, so never copy mssql.key. In tools that support it, you can pin the fingerprint instead.

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 2022 Standard'');'); SELECT id, body FROM demo.dbo.notes; DROP DATABASE demo;"

id body -- ---- 1 hello from SQL Server 2022 Standard

For an application, create a dedicated login and database instead of using sa. Run the statements below 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

SQL Server listens on port 1433 on the VM's network interfaces with encryption forced, so a client on another host can connect once your network security group allows it. Allow TCP 1433 only from the addresses that need it, never from Internet or *.

az network nsg rule create --resource-group <your-resource-group> --nsg-name <your-vm-nsg> \
  --name allow-sql-from-app --priority 310 --access Allow --protocol Tcp --direction Inbound \
  --source-address-prefixes <client-ip-or-cidr> --destination-port-ranges 1433

From the VM itself, confirm that the private address accepts an encrypted session:

export SQLCMDPASSWORD="$(sudo awk -F= '/^SA_PASSWORD=/{print $2}' /root/mssql-credentials.txt)" /opt/mssql-tools18/bin/sqlcmd -S "$(hostname -I | awk '{print $1}'),1433" -U sa -C -No -h -1 -Q "SET NOCOUNT ON; SELECT CAST(client_net_address AS varchar(20)) + ' encrypted=' + CAST(encrypt_option AS varchar(5)) FROM sys.dm_exec_connections WHERE session_id = @@SPID"

10.0.0.12 encrypted=TRUE

Connect SQL Server Management Studio, Azure Data Studio, VS Code or your application to <vm-ip>,1433. Use SQL Server authentication as sa (or your application login) and set encryption to Mandatory. Either trust the server certificate or install mssql.pem as a trusted certificate (Step 6).

The certificate names the VM's hostname, localhost and its private address. 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).

To keep port 1433 closed to the network entirely, bind SQL Server to the loopback address and use an SSH tunnel (ssh -N -L 1433:127.0.0.1:1433 azureuser@<vm-public-ip>):

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

Sign in to the AWS Management Console, open the EC2 service and select Launch instance. Under Application and OS Images, choose AWS Marketplace AMIs and search for SQL Server 2022. Select the SecureAnyCloud listing and choose Select. On the subscription summary, pick the SQL Server 2022 Standard on Ubuntu 22.04 delivery option and choose Continue.

Pick an instance type that suits your workload (see Prerequisites). Choose your EC2 key pair under Key pair (login). Under Network settings, select your VPC and subnet, and a security group that allows inbound port 22 from your management network. Add port 1433 if external clients must connect to SQL Server directly. The AMI brings its own data volume, so leave the block device mappings at their defaults.

Select Launch instance. First-boot initialization generates the SA password and starts SQL Server. It takes a minute or two after the instance state becomes Running and the status checks pass.

Replace <ami-id> with the AMI ID shown on the Marketplace listing for the Standard delivery option. Replace the network and key values in angle brackets with your own.

aws ec2 run-instances \
  --image-id <ami-id> \
  --instance-type m5.xlarge \
  --key-name <key-name> \
  --subnet-id <subnet-id> \
  --security-group-ids <security-group-id> \
  --metadata-options HttpTokens=required \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=mssql-01}]'

The data volume is defined in the AMI, so you do not need to specify it. Once the instance is running, retrieve its public address:

aws ec2 describe-instances --instance-ids <instance-id> \
  --query "Reservations[].Instances[].PublicIpAddress" --output text

Wait until the instance has passed both EC2 status checks. This delivery option is built on Ubuntu 22.04, so the SSH login user is ubuntu:

ssh ubuntu@<your-instance-ip>

The first-boot service writes the per-instance credentials to /root/mssql-credentials.txt (root-only). Read the file:

sudo cat /root/mssql-credentials.txt

The file looks like this. Your instance has its own unique passwords.

# SQL Server 2022 Standard Edition -- Per-Instance Credentials
# Generated: Wed Jun 04 09:00:00 UTC 2026
# SA_USER=sa SA_PASSWORD=<set-at-first-boot> SAC_USER=sac SAC_PASSWORD=<set-at-first-boot> SAC_DATABASE=sac

The SecureAnyCloud login has db_owner on the SecureAnyCloud database and is suitable for application connections.

Connect as sa over the loopback address.

SA_PASS=$(sudo grep '^SA_PASSWORD=' /root/mssql-credentials.txt | cut -d= -f2-) /opt/mssql-tools18/bin/sqlcmd -S 127.0.0.1 -U sa -P "${SA_PASS}" -C

The -C flag trusts the self-signed server certificate. Type GO to run a batch and exit to quit.

Query the server version:

SA_PASS=$(sudo grep '^SA_PASSWORD=' /root/mssql-credentials.txt | cut -d= -f2-) /opt/mssql-tools18/bin/sqlcmd -S 127.0.0.1 -U sa -P "${SA_PASS}" -C -Q "SELECT @@VERSION"

The output resembles the following. The edition line shows this image's Standard edition.

Microsoft SQL Server 2022 (RTM-CU25) (KB5054531) - 16.0.4255.1 (X64) May 20 2026 12:06:45 Copyright (C) 2022 Microsoft Corporation Standard Edition (64-bit) on Linux (Ubuntu 22.04.5 LTS) <X64>

Check the service status:

sudo systemctl status mssql-server --no-pager

Manage the service with sudo systemctl {stop,start,restart} mssql-server.

SQL Server data and log files are stored on a dedicated gp3 EBS volume mounted at /var/opt/mssql, separate from the OS disk. Confirm the mount:

df -h /var/opt/mssql lsblk

To grow the volume, resize the EBS volume in the AWS console, then extend the filesystem on the instance:

sudo resize2fs $(findmnt -no SOURCE /var/opt/mssql)

Create a database and a table, insert a row and read it back:

SA_PASS=$(sudo grep '^SA_PASSWORD=' /root/mssql-credentials.txt | cut -d= -f2-) /opt/mssql-tools18/bin/sqlcmd -S 127.0.0.1 -U sa -P "${SA_PASS}" -C -Q "IF DB_ID('myapp') IS NULL CREATE DATABASE [myapp];" /opt/mssql-tools18/bin/sqlcmd -S 127.0.0.1 -U sa -P "${SA_PASS}" -C -d myapp -Q "IF OBJECT_ID('customers') IS NULL CREATE TABLE customers (id INT IDENTITY PRIMARY KEY, name NVARCHAR(100), email NVARCHAR(200)); INSERT INTO customers (name,email) VALUES ('Alice Smith','alice@example.com'); SELECT id,name,email FROM customers;"

SQL Server listens on port 1433. Add port 1433 to the security group, then connect with SSMS, Azure Data Studio, DBeaver or sqlcmd:

/opt/mssql-tools18/bin/sqlcmd -S <your-instance-ip>,1433 -U sa -P "<SA_PASSWORD>" -C

Create a backup folder owned by the mssql user and back up the SecureAnyCloud database with compression:

sudo mkdir -p /var/opt/mssql/backup && sudo chown mssql:mssql /var/opt/mssql/backup
SA_PASS=$(sudo grep '^SA_PASSWORD=' /root/mssql-credentials.txt | cut -d= -f2-) /opt/mssql-tools18/bin/sqlcmd -S 127.0.0.1 -U sa -P "${SA_PASS}" -C -Q \
  "BACKUP DATABASE [sac] TO DISK = N'/var/opt/mssql/backup/sac.bak' WITH INIT, COMPRESSION;"