EC2 vs Azure VM vs On-Premises

Features

SQL Server on AWS EC2

SQL Server on Azure VM

SQL Server On-Premises

Deployment

User deploys an EC2 VM and installs SQL (AWS provides pre-built SQL AMIs)– faster than on-prem, but manual SQL config required.

User deploys an Azure VM (with a SQL image if desired) – similar to EC2, quick to create but you manage SQL setup.

Provision hardware/VMs and install OS and SQL – slowest option, entirely manual (weeks to procure if new hardware).

Management

Fully self-managed: you handle OS/SQL patches, backups, monitoring.

Self-managed, though Azure offers a VM extension for automating SQL patching/backups.

Fully self-managed by your IT team (complete responsibility for maintenance).

Customization

Maximum – full OS control, any SQL version/settings, install any software.

Maximum – complete OS and SQL control, legacy versions supported.

Unlimited – choose any hardware, OS, SQL configuration (most flexible).

Use Case

When full control is needed in AWS (e.g., custom configurations or unsupported features) ; lift-and-shift with minimal cloud modifications.

When full control is needed in Azure (legacy apps, custom integrations, SSRS/SSAS); a bridge between on-prem and cloud with control.

Ideal for strict data control, low-latency to on-prem apps, or existing data center investments; also when compliance or legacy systems mandate it.

Maintenance Responsibility

You/your DBAs – AWS doesn’t patch your EC2 instances or SQL (user schedules and applies updates).

You/your team – unless using Azure’s IaaS Agent to auto-patch, you handle updates.

Your IT team entirely – on-prem requires internal processes for all updates.

Operational Control

Full sysadmin rights on SQL and admin on OS – complete freedom (and responsibility).

Full control – you can even remote desktop to OS and change anything.

Complete control at hardware, OS, and DB level – no restrictions (can even delay patches indefinitely, for example).

Backups

Must be set up by user (e.g., backup to S3 or EBS, or use AWS Backup service); automated backup = none by default.

User-managed (can use Azure Backup or SQL Agent jobs, or enable the SQL VM backup extension for Azure-managed backups)

Completely on user – typically use maintenance plans or enterprise backup tools writing to tapes/cloud.

Scalability

Vertical: change EC2 instance type (manual, downtime); Horizontal: add more VMs and configure clustering or load splitting manually (no built-in auto-scale).

Vertical: change VM size (reboot required); Horizontal: add more VMs (e.g., Always On AG for read scale) – manual setup.

Vertical: buy/upgrade hardware (major project); Horizontal: add servers and distribute load (requires significant effort and maybe app changes).

Performance

Can be very high (depends on instance and EBS setup): e.g., EC2 with Provisioned IOPS SSD can hit tens of thousands of IOPS; you can tune everything (Storage cache, TempDB on instance store, etc.).

High (depends on chosen VM and disks): you can use Premium SSD/Ultra Disk on Azure VMs and optimize like on-prem – performance is as good as the hardware allows, with full control.

Potentially the highest (you can use top-end hardware, dedicated storage arrays, etc.); ultimate performance if budget allows, with no virtualization overhead if physical.

Elasticity

No native auto-scaling – fixed resources unless manually changed; you’d need custom scripts or AWS Auto Scaling Groups (not typical for DB VMs) to simulate elasticity.

No native auto-scale – you set a VM size; possible to script something with Azure Automation to scale VMs on a schedule or metric, but it’s user-implemented.

None – capacity is fixed once purchased. Scaling requires planning and manual execution (or new hardware purchase).

SQL Server Version

Any version you want (you install it). AWS SQL AMIs typically offer 2016–2019 and now 2022, but you could install an older one manually if needed (not recommended, but possible).

Any version (since you control the install media). Azure marketplace images cover currently supported versions (2012+), but you could bring older versions on a custom image if absolutely needed.

Any version/edition for which you have media and license – including very old versions (some orgs still run 2008 or 2005 for legacy apps, which on-prem allows, albeit unsupported by MS).

SQL Feature Support

All features supported – it’s a full SQL Server. (If Windows, features like SSRS/SSAS need separate installation but can be on the same VM or another.) No artificial restrictions – you can even enable unsupported stuff at your own risk.

All on-box features supported – you can install SSRS on the VM, use SSIS, enable ML Services, etc., just as on a normal server. No limitations beyond what SQL Server normally has.

Everything SQL Server offers is available if you set it up – including things like replication, Linked Servers, Service Broker, etc. You have to configure them, but nothing is disabled by a provider.

Cross-Database Queries

Yes, you can query across DBs on the same instance or use linked servers between instances – same as normal SQL.

Yes, within the SQL instance on that VM you can do cross-database joins/transactions.

Yes, common on on-prem to have many DBs on one server and join them. Also, cross-server via linked server is possible.

Custom Software

Yes – install anything on the VM (e.g., anti-virus, monitoring agents, custom CLR assemblies in SQL, etc.). You have OS access to do so.

Yes – you can treat it like any Windows server: for example, install Splunk forwarders, custom performance collectors, or even run other apps on the same VM (if resources allow).

Yes – common to have monitoring agents (SCOM, etc.) on SQL servers, or backup agents. You could even run a third-party application on the same machine (though best practice is to separate, it’s up to you).

Network Configuration

Runs in AWS VPC – you control subnet placement, security groups, routing (it’s like any other VM). You can give it a public IP or keep it private. It integrates with on-prem via VPN/Direct Connect seamlessly.

Runs in Azure VNet – full control over IP address, subnet, NSGs, etc., like any VM. You can even place multiple VMs in the same subnet for cluster setups. Connect via ExpressRoute/VPN to on-prem easily.

On your corporate network – ultimate control (your own firewall, switches, VLANs). You can make it as open or isolated as you need. Typically behind corporate firewalls and accessible only within company network.

Security

You manage security: enable TDE if needed (with your own key or certificate), use AWS KMS for volume encryption (just a checkbox on EBS), configure Windows Firewall or AWS Security Groups. Compliance depends on your configuration – AWS provides baseline (e.g., you can use AWS Config/Audits, but it’s on you to implement security best practices).

Similar to EC2: you manage OS hardening, patches, SQL security config. Azure can encrypt disks by default, and you can use Azure Key Vault for TDE keys. Azure VM itself is an isolated environment you control. Compliance again is on how you set it up (Azure just provides infrastructure that can be compliant if you configure it so).

Entirely on you – from physical security of the server room, to network security, to OS and SQL security. You can achieve very high security (even completely air-gapped networks), but it requires strict processes. Encryption (TDE, etc.) must be configured by you.

Authentication

Windows Auth (AD) and SQL Auth both supported – it’s just a normal SQL Server in a Windows environment. You’d typically join the EC2 to your domain to use integrated auth.

Windows Auth and SQL Auth supported – join the VM to a domain (on-prem AD or Azure AD Domain Services) and you get integrated security. You can also use contained database users, etc., just like on-prem.

Windows Auth and SQL Auth – often tightly integrated with on-prem AD. You can enforce AD group policies, etc. If not on a domain, SQL Auth is used. No cloud-specific auth out of the box (though you could integrate Kerberos and AD FS if needed for fancy setups).

High Availability

Must be configured by user (e.g., Always On AG across two EC2s in different AZs). EC2 itself can be put in an Auto-Recovery, but that’s infrastructure-level. True HA = you set up clustering or AG, which is complex but doable (Launch Wizard can assist).

Must be configured by user – e.g., Always On AG across VMs or a Failover Cluster with Azure Shared Disks or Azure FSx for SMB. Azure provides multi-AZ (multi-zone) VM placement for resilience, but SQL HA is your responsibility.

Many options but all manual: Failover Cluster Instances (with shared storage like SAN), Always On AG, database mirroring (old), log shipping as quasi-HA. Requires redundant hardware and networking. You manage failover process (though AG can auto-failover).

Disaster Recovery

User-defined: e.g., set up an async AG to a second region’s EC2, or do periodic backups to an offsite location and plan for restore. AWS doesn’t automatically replicate EC2-based SQL to another region – you must architect it.

User-defined: e.g., use Azure Site Recovery to replicate the VM to another region, or set up an AG with a replica in a secondary region for DR. Azure won’t auto-handle cross-region failover for VMs – your DR plan executes it.

Entirely on you: could be as robust as a secondary data center with log shipping or AGs, or as basic as offsite backup tapes. DR testing and execution are your ops team’s duty.

Pricing

Pay for EC2 VM + storage + bandwidth. E.g., $2.0k/month for an 8vCPU VM with SQL Std license. If BYOL, you pay cloud costs ($700) and use your own license (~$1.3k amortized) separately. Reserved Instances can cut EC2 cost ~30-50%.

Pay for Azure VM + storage. E.g., ~$1.5-2k/month for 8 vCPU VM with SQL Std included. Using Hybrid Benefit (BYOL) might drop that to ~$1k (just VM). Azure RIs can save ~30%. Network egress (if any) is extra.

Big upfront CapEx for hardware & licenses, then minor OpEx (power, cooling). Amortized 3-year cost for an 8-core server might be ~$1-3k/month depending on edition (Standard vs Enterprise), but you own the asset. Scaling requires new investment.

Licensing Model

License-Included or BYOL. Can use on-demand hourly (with Windows/SQL licensing bundled) or bring your own licenses (requires Software Assurance for mobility). BYOL on EC2 can run on Dedicated Hosts or via License Mobility on shared tenancy.

License-Included or BYOL. Azure Hybrid Benefit lets you apply existing licenses; or pay-as-you-go includes SQL license. Per-second billing. Enterprise Agreement customers can also get dev/test pricing without SQL costs on Azure for non-prod.

Perpetual or Subscription licenses. Typically purchase per core (Enterprise ~$7.5k/core, Standard ~$1.9k/core) plus optional SA ~25%/yr. Hardware bought or leased separately. No builtin pay-per-use; however, you could run SQL Developer or Express free in non-prod.

Pricing Comparison of Database Configuration

8vCore + 4TB Data size + Backup,  Single Instance

~$2,000/month (license-included Std) for m5.2xlarge + 4TB gp3 on AWS.
BYOL could lower cost if you already own a license.
On-prem roughly equivalent ~$1k (Std) to $3k (Ent) when amortized, but cloud includes hardware + management overhead.

~$1,700/month for 8 vCore GP Azure MI or SQL DB (license included);
~$1,500/month for Azure VM (license included) or ~$1,000 with BYOL.
On-prem ~$1k (Std) as above.

On-prem not monthly billed, but roughly ~$1k (Std) / ~$3k (Ent) per month value when spread over a few years.

8vCore + 4TB Data size + Backup + DR/HA

EC2: ~$4,000/month for two instances (Multi-AZ).

HA requires a secondary VM (8 vCore + 4TB) but incurs no extra SQL Server license cost if using Azure Hybrid Benefit.
For DR, a geo-replicated secondary adds ~$1,800/month, bringing total costs to ~$3,400/month (excluding SQL license).
Backup adds ~$120/month. Without Azure Hybrid Benefit, SQL Server licensing adds ~$2,500/month, pushing total cost to ~$5,900/month.
DR and HA both require paying for full VM resources; SQL license charges apply to all nodes unless covered by Hybrid Benefit.

Multi-site on-prem: requires second set of hardware (and possibly second license if active-active).
Hard to monthly-ize, but essentially 2× hardware cost; SQL license for passive is free with SA.