As mentioned, you can either create a VM and install SQL Server later, or you can choose an image that already has SQL Server included. In this case, I'm going to choose an image named SQL Server 2016 SP1 Enterprise Edition which already has SQL Server included. This VM is based on Windows Server 2016, and this is going to be our OS.
Most options are very similar to options that we had when SQL Server wasn't included in the image used to create a virtual machine. We start with basic information, where we have to provide a Name, VM disk type, Username, Password, Subscription, Resource group, and Location. I strongly recommend you use SSD as the VM disk type when creating a VM that will run SQL Server.
Disk speed has big impact on SQL Server performance, and selecting a faster disk type will help you get the best performance. A list of all basic settings and an example is shown in the screenshot:
Our next step is to select the size of the VM. Based on the disk type, the list will be limited to sizes that support only the disk type selected. When selecting the size for the VM that will run SQL Server, I recommend selecting more CPU and memory. SQL Server requires resources, and selecting the right size is beneficial for performance. Luckily, if you select a size that is too big or too small, you can change it later. This is one of the cloud computing perks, and you are not stuck with the initial size. A list of VM sizes based on SSD are shown in the following screenshot:
The Settings blade has all the options we have used before and we can set a default for everything. If you intend to set up high availability for your SQL Server, make sure you select Availability zone and Availability set now, as this cannot be done later. Also, take note of the Network, Subnet, and Network Security Group that the VM is going to be connected to. If multiple subnets are in use, you probably don't want SQL Server to end up in DMZ. The same goes with NSG—you probably want different security settings for SQL Server than Web Server. Luckily, these settings can be changed later. An example of the Settings is shown in the screenshot:
Finally, we have a set of settings which are specific to images with SQL Server and can't be found when creating VMs that don't have SQL Server included. In SQL Server settings we can configure SQL connectivity, SQL Authentication, Storage configuration, Automated patching, Automated backup, Azure Key Vault integration, and R Services (Advanced analytics).
SQL connectivity allows us to set up the connectivity level and port. For the connectivity level, we can allow connection to the SQL Server only from within the VM: Private (from Virtual Network) and Public (over internet). I strongly recommend not using public access to SQL Server. This will expose your databases to access over the internet; anyone can try to gain access and you're exposing the database to brute force attacks. Access to SQL Server only from within the VM may not be an option either, unless you run everything on a single VM and intend to run the application on the same server. Most often the scenario will be private access from within the virtual network, allowing other VMs on the same network to access the database. The default Port for SQL Server will be 1433 but can be changed if needed.
Default authentication for SQL Server will be Windows authentication, but you can Enable SQL Authentication if needed. If SQL Authentication is enabled, the username and password used for the VM will be added as the SQL login as well.
Storage configuration is Not available at this time and this setting will be used after the VM is created.
Automated patching is set to Sunday at 2:00 by default. This setting can be changed to another time, or it can be Disabled. I recommend not disabling it, as this will ensure your SQL Server is up to date and patched with the latest updates, including security updates. However, in some cases, you need to test updates before installing them, so in this case you want to disable them. Note that, in this case, you are responsible for keeping the server up to date.
Automated backup is Disabled by default. If Enabled, you have multiple options available. You can select the storage account in which backups will be placed; the retention period is 30 days by default, and it can be set to a lower value (minimum 1 and maximum 30 days). Backup encryption can be set to on or off; system database backup can be included if needed. The last option is to configure the backup schedule. Automatic backup, set by default, will perform backup operations weekly. You can change this setting to daily. You can set up a time for backup, as well as the frequency. (This can be configured to back up the database from every 5 minutes to once a day.)
The last two options are Azure Key Vault integration and R Services (Advanced analytics), and these allow you to Enable these features if needed. Azure Key Vault will require Key Vault information that will be used, and R service will simply install additional analytics features.
An example of SQL Server settings is shown in the following image:
Deploying Azure Virtual Machine with SQL Server takes a little longer than deploying a similar VM without SQL Server. This is due to passing additional information and configuring the SQL Server instance inside the VM.