SQL Server 2022 Web

In Azure Marketplace, search for SQL Server 2022 Web, select the SecureAnyCloud offer and choose Create.

On the Basics tab, choose your subscription, resource group and region, and name the VM. Choose Standard_D4s_v3 or larger (SQL Server needs at least 2 GB of memory) and 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. Select Review + create, then Create.

Accept the Marketplace terms once per subscription, then create the VM (replace the values in angle brackets):

az vm image terms accept --urn sac1647283583153:mssql-2022-web-ubuntu-22-04:default:latest
az vm create \
  --resource-group <your-resource-group> \
  --name sql-web-01 \
  --image sac1647283583153:mssql-2022-web-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.

SSH to the VM:

ssh azureuser@<vm-public-ip>

Check 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 an internal SQL Server port. 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"))

Only root can read the credentials file. 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 1170 Oct 23 15:24 /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. The password 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 the password 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), but the blocks use the full path.

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

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

An engine_edition of 2 is the Standard engine, which Web edition runs.

SQL Server forces encryption, so even a client that asks only for optional encryption (-No) gets an encrypted session. Check the 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 VM's own, named after its hostname (the VM name) and addresses. Inspect it, as in this example:

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

subject=CN = mssql-web-2204-simA-10231437-c1a604 notAfter=Oct 20 15:21:18 2036 GMT X509v3 Subject Alternative Name: DNS:mssql-web-2204-simA-10231437-c1a604, DNS:localhost, IP Address:127.0.0.1, IP Address:10.0.0.12 sha256 Fingerprint=52:A6:F6:A8:99:AC:90:3F:8D:5D:29:D4:D3:77:CF:EE:91:F3:DC:FB:10:82:CC:A7:29:47:37:B1:CF:5C:ED:97

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 certificate. 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-web-2204-simA-10231437-c1a604

On your workstation, copy /etc/ssl/mssql/mssql.pem (the public certificate, never mssql.key) and add it to the client's trusted certificates. 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 Web'');'); SELECT id, body FROM demo.dbo.notes; DROP DATABASE demo;"

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

For an application, create a dedicated login and database instead of using sa. Run the following 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. 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. A client that connects 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 Web 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 you want external clients to 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 Web delivery option. Replace the other values in angle brackets with your own network and key details:

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 AMI defines the data volume, so you do not need to specify it. When 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, then connect over SSH. This delivery option is built on Ubuntu 22.04, so the 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 as root:

sudo cat /root/mssql-credentials.txt

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

# SQL Server 2022 Web 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 the db_owner role on the SecureAnyCloud database and is suitable for application connections.

Read the SA password from the credentials file and open a sqlcmd session:

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 reflects this image's Web edition:

Microsoft SQL Server 2022 (RTM-CU25) (KB5054531) - 16.0.4255.1 (X64) May 20 2026 12:06:45 Copyright (C) 2022 Microsoft Corporation Web 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, add a table and insert a row:

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 directory and back up the SecureAnyCloud database to it:

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;"