SQL Server on AWS: RDS against EC2, feature by feature

About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not a lab validation of the procedures. Check the stated versions and your own recovery requirements before making changes.

Choose Amazon RDS for SQL Server when the application can live without operating system access or the sysadmin role, and uses none of the features RDS removes. Choose SQL Server on EC2 when it needs either, or when you must control backups and high availability yourself. RDS Custom sits between them for packaged applications that need operating system access.

The decision is usually settled by a short inventory of server-level dependencies, not by instance size. The queries below find most of those dependencies, and their gaps are listed after them. They and the AWS procedures shown were checked against vendor documentation. None was run in a lab.

Why it matters

RDS is SQL Server with the server taken away. The engine is real, but server-level control belongs to AWS. A database can restore cleanly and still fail in production because a job step used PowerShell, an assembly was marked UNSAFE, or a report depended on a linked server that was created after Multi-AZ was turned on and never reached the standby.

EC2 gives you more configuration choices, subject to SQL Server edition and platform support, and every patch, backup, failover test and licence count is now yours.

How the control boundary works

On RDS there is no shell, Telnet, SSH or Remote Desktop access to the host. The master login is a member of processadmin, public and setupadmin. The roles sysadmin, serveradmin, securityadmin, dbcreator, diskadmin and bulkadmin are unavailable. So are permissions such as CONTROL_SERVER, ALTER ANY DATABASE, CREATE ENDPOINT, SHUTDOWN and UNSAFE ASSEMBLY.

Administrative work moves into AWS procedures in msdb, parameter groups and option groups.

On EC2, AWS describes the choice as full control over the database and the operating system, with you administering backups, recovery, patching, security and high availability.

RDS Custom gives administrative rights to the database and the underlying operating system while AWS keeps automating setup and backups. It has its own limits: no read replicas, no custom parameter or option groups, no Performance Insights, no RDS Proxy and no automatic minor upgrades. It also runs a support perimeter. Stopping or terminating the host yourself puts the instance outside it. If the host is replaced, database data is retained, but anything on the C: drive is lost.

Feature comparison

The RDS column comes from AWS's unsupported features list and the pages linked in later sections. The EC2 column means self-managed SQL Server, so availability follows Microsoft's edition limits.

SQL Server 2022 on RDS also leaves out suspend for snapshot, External Data Source, S3-compatible backup, object store integration, TLS 1.3 with MS-TDS 8.0, and QAT. 2025 additionally omits ZSTD backup compression. The newest engine is where the gap is widest, so check the list for the exact major version.

SQL Server Agent on RDS runs, but with no ActiveX, cmd or PowerShell steps, no replication jobs, no alerts and operators, no Agent email notifications and no backups through Agent.

Inventory before you choose

These queries are written for this article from Microsoft's catalog view documentation. Run them read-only on the current source server.

Server level:

SELECT name, source_database_id, is_trustworthy_on, is_published,
       is_merge_published, is_distributor, recovery_model_desc, state_desc
FROM sys.databases;

SELECT name, is_disabled FROM sys.server_triggers WHERE is_ms_shipped = 0;

SELECT name, type_desc FROM sys.endpoints WHERE endpoint_id >= 65536;

SELECT name, product, data_source FROM sys.servers WHERE is_linked = 1;

SELECT subsystem, COUNT(*) AS steps
FROM msdb.dbo.sysjobsteps GROUP BY subsystem;

SELECT primary_database FROM msdb.dbo.log_shipping_primary_databases;

In each user database:

SELECT name, type_desc FROM sys.database_files WHERE type_desc = 'FILESTREAM';
SELECT name, permission_set_desc FROM sys.assemblies WHERE is_user_defined = 1;

These queries have gaps. Custom extended procedures and Agent alerts and operators need a separate check. Replication subscribers are not found, because is_subscribed is unused and always returns 0. A source already running an availability group will show its endpoint as a user endpoint. Our reading is that this is not a blocker by itself, because RDS Multi-AZ takes over that role.

Then count databases against the RDS limits. Classes from xlarge to 16xlarge allow 100 databases Single-AZ, 50 with Database Mirroring and 75 with Always On. large classes allow 30 in all three modes. On 24xlarge to 32xlarge with 96 or more vCPUs, Always On allows 100. Micro to medium allow 30 Single-AZ and no Multi-AZ.

Also check connection details. RDS reserves ports 1234, 1434, 3260, 3343, 3389, 47001 and 49152 to 49156, and does not permit clients from 169.254.0.0/16.

Backup and restore

This is the widest operational difference after permissions.

RDS takes automated volume snapshots of the whole instance and uploads transaction logs every five minutes. Snapshot and point-in-time restores of the instance go to a new instance, at any point in the retention period. Native restore, covered below, brings a database into an existing instance under an unused name. On instance restore, each database lands within one second of the others, so cross-database transactions may be inconsistent.

Point-in-time recovery has conditions an administrator on EC2 would not expect. Taking a database OFFLINE, EMERGENCY or SINGLE_USER stops the latest restorable time for the whole instance. A change of recovery model can break the log sequence. AWS names two common causes of a gap: manual changes, and automatic changes by RDS when it lacks the resources to complete log backups. The second is a sizing risk. A sequence gap puts a restoring instance in incompatible-restore. Check the sequence with:

SELECT * FROM msdb.dbo.rds_fn_list_tlog_backup_metadata('database_name')
ORDER BY backup_file_time_utc DESC;

Native backup needs the SQLSERVER_BACKUP_RESTORE option and an IAM role. Its limits shape the runbook:

• The S3 bucket must be in the same Region as the instance.
• 5 TB per file, up to 10 files.
• Up to two backup or restore tasks at once.
• A native backup is cancelled if it overlaps the daily backup window.
• A native backup cannot run during the maintenance window or while RDS is taking a snapshot.
• Native restores are not supported on instances with cross-Region read replicas.
• Native restores on Express Edition are limited to 10 GB.
• You cannot restore over an existing database name.
• You cannot take native log backups from RDS. RDS does offer read access to the last seven days of its log backups, copied to an S3 bucket in the same account and Region. AWS describes using them for point-in-time restores of a database without restoring a whole instance. Cross-account and cross-Region copy is not supported, and the page does not say whether the files restore on a server outside RDS.
• On Multi-AZ, you can natively restore only databases backed up in the full recovery model.

You can apply log backups to RDS, which suits migration. A cutover can restore a full backup with NORECOVERY, apply logs, then finish:

exec msdb.dbo.rds_restore_database
  @restore_db_name='mydatabase',
  @s3_arn_to_restore_from='arn:aws:s3:::mybucket/backup1.bak',
  @with_norecovery=1;

exec msdb.dbo.rds_restore_log
  @restore_db_name='mydatabase',
  @s3_arn_to_restore_from='arn:aws:s3:::mybucket/mylog.trn',
  @with_norecovery=1;

-- Run each step on its own. Confirm every task above has finished,
-- because the database must have no pending restore tasks.
exec msdb.dbo.rds_task_status @db_name='mydatabase';

exec msdb.dbo.rds_finish_restore @db_name='mydatabase';

The status procedure is updated about every two minutes.

On EC2 you own the design. AWS documents server-level backups through VSS-enabled EBS snapshots and AWS Backup, and database-level native backups to EBS, FSx or S3 through Storage Gateway. For VSS restores, set the database to full recovery first and run AWSEC2-VssInstallAndSnapshot with SaveVssMetadata set to True.

High availability

RDS picks the Multi-AZ technology by version and edition: Always On availability groups, Database Mirroring or, on some Web Edition versions, block-level replication. Confirm which one you have:

EXEC msdb.dbo.rds_get_high_availability_option;

The limits matter more than the mechanism. AWS's Multi-AZ limitations include a single standby that cannot serve reads and cannot sit in another Region. All databases fail over as one unit. The Always On listener does not support Kerberos, because it has no Service Principal Name. An instance in a Multi-AZ deployment cannot be stopped.

Not everything replicates. With Mirroring or Availability Groups, logins do, but linked servers do not, because they are stored in master. Create them before enabling Multi-AZ, or recreate them on the new primary after a failover. Server audits and msdb permissions are also not replicated. Agent job and tempdb synchronisation is optional. Inventory the configured objects with this read-only query; enabling synchronisation needs a separately reviewed plan because the primary becomes authoritative:

SELECT * FROM msdb.dbo.rds_fn_get_system_database_sync_objects();

The primary is the source of truth. Make sure every job is on the primary before turning replication on, or newer jobs on the secondary can be deleted. Only T-SQL job steps in supported categories replicate.

Port 3343 must be allowed for TCP and UDP, in both directions, in the network ACLs and the instance's security group. AWS says this traffic is only required within the VPC.

Read replicas need Enterprise Edition and a class with four or more vCPUs. You can have up to 15, with possible lag above five, and you cannot choose which databases replicate. Logins are not synchronised, and replicas are upgraded first, with the primary following immediately regardless of the maintenance window.

On EC2 you can build failover cluster instances or Always On availability groups, and edition sets the ceiling. In SQL Server 2022, Enterprise allows 16 failover nodes and up to eight secondaries, five of them synchronous. Standard allows two failover nodes or a basic availability group: two replicas, one database, no read access and no backups on the secondary.

The cluster design rules differ from on-premises practice. Every cluster counts as multi-site, because EC2 does not share IP addresses virtually, so each node needs its own subnet. Each node should use one network interface carrying a primary IP, a cluster IP and one IP per availability group. A second interface for heartbeat brings no benefit, because it shares the same infrastructure and bandwidth. If clients are not multi-subnet aware, AWS gives a procedure for setting RegisterAllProvidersIP to 0.

Storage and scale

The detailed sections of AWS's storage page give RDS for SQL Server the same per-volume ceilings as EBS for the two recommended SSD types. If those figures hold for your engine version, the volume number alone does not force a move to EC2.

AWS's pages disagree. The SQL Server overview gives 16 TiB for General Purpose storage. The storage page contradicts itself, with 65,536 GiB in its gp3 table and 16,384 GiB for SQL Server in its comparison table. Confirm the real limit in the console for your engine version before designing around it.

AWS also warns that a workload might not achieve all the IOPS provisioned, and that an instance class with lower limits cannot fully use what additional volumes offer.

RDS can add up to three extra volumes as H:, I: and J:, for up to 256 TiB in total. This is limited to Standard, Enterprise and Developer Enterprise, and to gp3 or io2. It cannot be combined with read replicas or cross-Region automated backup, and files cannot be moved between volumes.

Some RDS classes place tempdb on instance store automatically. On EC2 you choose the layout, including FSx for shared storage.

Edition limits apply on both. Standard in SQL Server 2022 stops at the lesser of four sockets or 24 cores and 128 GB of buffer pool. AWS's feature page gives four sockets or 32 cores and 256 GB of buffer pool for 2025 Standard.

Licensing

Three points are easy to miss.

• RDS Bring Your Own Media does not support in-place major version upgrades. You create a new instance and migrate with native backup and restore.
• On EC2, SQL Server licences without active Software Assurance can only go on Dedicated Hosts, must predate 1 October 2019 or be a true-up under an enrolment effective before that date, and can only be upgraded to versions available before then.
• Amazon EC2 High Availability for SQL Server waives the SQL Server fee on qualifying standby nodes on licence-included instances. It needs SQL Server 2017 or later on Windows Server 2019 or later, all nodes in one account and Region, and a standby that serves no traffic and is not a readable secondary. It does not work with Reserved Instances, and AWS says the feature may be terminated.

Web Edition on RDS can be created only from the Dev/Test template, and its use is restricted by section 10.5 of the AWS Service Terms. Read those terms against the workload. Microsoft says Web edition is not available in SQL Server 2025 and later, so the option applies only to earlier versions.

Patching and versions

RDS applies minor versions manually or, if you enable it, automatically in the maintenance window when critical security updates are available. Operating system updates are applied during engine upgrades. When checked for this article, the newest listed minor was SQL Server 2025 CU10, 17.0.5035.5, released 22 October 2026.

Versions on EC2 are whatever you install, and AWS lists avoiding automatic patches that may not suit your application as a reason to choose it.

What to choose and why

These are editorial recommendations.

Choose RDS when the inventory comes back clean, the databases fit the limits and your team would rather not run failover clusters. Accept that instance and point-in-time restores go to a new instance, and that you cannot take your own log backups. Only the last seven days of RDS's log backups can be copied out, and AWS does not document restoring them outside RDS.

Choose EC2 for any hard blocker in the inventory, SQL Server 2025 with SSIS, an application that requires sysadmin, an existing log-shipping or replication design, or a failover design that needs more than one standby in the high-availability role.

Choose RDS Custom only for a packaged application that needs host access and whose vendor accepts the support perimeter. Test host replacement, given what is lost on C:.

Choose per database, not per estate. AWS itself notes that many customers run SQL Server workloads across both.

Risks and limits

Warning: On RDS Multi-AZ, do not run SET PARTNER off or SET RECOVERY simple, and do not set DEFAULT_DATABASE on logins except with block-level replication. AWS lists these as things to avoid.

Warning: Restoring an RDS instance to a point before a DROP DATABASE typically returns that database to its state up to five minutes before the drop. Test the restore path, and do not assume the last transactions are recoverable.

Warning: Do not use the catalog queries above as proof that an application is safe. They find declared objects, not dynamic SQL, application-side use of xp_cmdshell or assumptions about the file system.

The EC2 column is a statement of what the product allows, not of what is configured. Every available feature on EC2 needs your own design, patching, monitoring and restore tests.

Some AWS pages disagree, as noted above. Limits should be re-checked in the console and in the service quotas for your account and Region. Prices were deliberately left out, because licence model, Region and commitment change them too much for a general comparison.

Sources

Opened 2026-11-10. Sources behind the corrections reopened 10 November 2026.

• Amazon RDS for Microsoft SQL Server
• Features not supported and features with limited support
• Unsupported server roles and permissions
• Native backup and restore: limitations
• Using native backup and restore
• Multi-AZ deployments for SQL Server
• Multi-AZ limitations, notes and recommendations
• Read replicas for SQL Server
• Amazon RDS DB instance storage
• Bring Your Own Media
• RDS Custom for SQL Server requirements and limitations
• Options to run SQL Server on the AWS Cloud
• Licensing for SQL Server on Amazon EC2
• SQL Server clustering on Amazon EC2
• Amazon EC2 High Availability for SQL Server
• Amazon EBS volume types
• Editions and supported features of SQL Server 2022
• Basic availability groups

This article was originally published on 10 November 2026.