Amazon RDS for Microsoft SQL Server (original) (raw)

Amazon RDS supports several versions and editions of Microsoft SQL Server. The following table shows the most recent supported minor version of each major version. For the full list of supported versions, editions, and RDS engine versions, see Microsoft SQL Server versions on Amazon RDS.

Major version	Service Pack / GDR	Cumulative Update	Minor version	Knowledge Base Article	Release Date
SQL Server 2022	Not applicable	CU18	16.0.4185.3	KB5050771	March 13, 2025
SQL Server 2019	Not applicable	CU32	15.0.4430.1	KB5054833	February 27, 2025
SQL Server 2017	Not applicable	CU31 GDR	14.0.3485.1	KB5046858	November 12, 2024
SQL Server 2016	SP3 GDR	CU14	13.0.6455.2	KB5046855	November 12, 2024

For information about licensing for SQL Server, see Licensing Microsoft SQL Server on Amazon RDS. For information about SQL Server builds, see this Microsoft support article about Where to find information about the latest SQL Server builds.

With Amazon RDS, you can create DB instances and DB snapshots, point-in-time restores, and automated or manual backups. DB instances running SQL Server can be used inside a VPC. You can also use Secure Sockets Layer (SSL) to connect to a DB instance running SQL Server, and you can use transparent data encryption (TDE) to encrypt data at rest. Amazon RDS currently supports Multi-AZ deployments for SQL Server using SQL Server Database Mirroring (DBM) or Always On Availability Groups (AGs) as a high-availability, failover solution.

To deliver a managed service experience, Amazon RDS does not provide shell access to DB instances, and it restricts access to certain system procedures and tables that require advanced privileges. Amazon RDS supports access to databases on a DB instance using any standard SQL client application such as Microsoft SQL Server Management Studio. Amazon RDS does not allow direct host access to a DB instance via Telnet, Secure Shell (SSH), or Windows Remote Desktop Connection. When you create a DB instance, the master user is assigned to the_db_owner_ role for all user databases on that instance, and has all database-level permissions except for those that are used for backups. Amazon RDS manages backups for you.

Before creating your first DB instance, you should complete the steps in the setting up section of this guide. For more information, see Setting up your Amazon RDS environment.

Topics

Common management tasks for Microsoft SQL Server on Amazon RDS

The following are the common management tasks you perform with an Amazon RDS for SQL Server DB instance, with links to relevant documentation for each task.

Task area	Description	Relevant documentation
Instance classes, storage, and PIOPS	If you are creating a DB instance for production purposes, you should understand how instance classes, storage types, and Provisioned IOPS work in Amazon RDS.	DB instance class support for Microsoft SQL Server Amazon RDS storage types
Multi-AZ deployments	A production DB instance should use Multi-AZ deployments. Multi-AZ deployments provide increased availability, data durability, and fault tolerance for DB instances. Multi-AZ deployments for SQL Server are implemented using SQL Server's native DBM or AGs technology.	Configuring and managing a Multi-AZ deployment for Amazon RDS Multi-AZ deployments using Microsoft SQL Server Database Mirroring or Always On availability groups
Amazon Virtual Private Cloud (VPC)	If your AWS account has a default VPC, then your DB instance is automatically created inside the default VPC. If your account does not have a default VPC, and you want the DB instance in a VPC, you must create the VPC and subnet groups before you create the DB instance.	Working with a DB instance in a VPC
Security groups	By default, DB instances are created with a firewall that prevents access to them. You therefore must create a security group with the correct IP addresses and network configuration to access the DB instance.	Controlling access with security groups
Parameter groups	If your DB instance is going to require specific database parameters, you should create a parameter group before you create the DB instance.	Parameter groups for Amazon RDS
Option groups	If your DB instance is going to require specific database options, you should create an option group before you create the DB instance.	Options for the Microsoft SQL Server database engine
Connecting to your DB instance	After creating a security group and associating it to a DB instance, you can connect to the DB instance using any standard SQL client application such as Microsoft SQL Server Management Studio.	Connecting to your Microsoft SQL Server DB instance
Backup and restore	When you create your DB instance, you can configure it to take automated backups. You can also back up and restore your databases manually by using full backup files (.bak files).	Introduction to backups Importing and exporting SQL Server databases using native backup and restore
Monitoring	You can monitor your SQL Server DB instance by using CloudWatch Amazon RDS metrics, events, and enhanced monitoring.	Viewing metrics in the Amazon RDS console Viewing Amazon RDS events
Log files	You can access the log files for your SQL Server DB instance.	Monitoring Amazon RDS log files Amazon RDS for Microsoft SQL Server database log files

There are also advanced administrative tasks for working with SQL Server DB instances. For more information, see the following documentation:

Limitations for Microsoft SQL Server DB instances

The Amazon RDS implementation of Microsoft SQL Server on a DB instance has some limitations that you should be aware of:

The maximum number of databases supported on a DB instance depends on the instance class type and the availability mode—Single-AZ, Multi-AZ Database Mirroring (DBM), or Multi-AZ Availability Groups (AGs). The Microsoft SQL Server system databases don't count toward this limit.
The following table shows the maximum number of supported databases for each instance class type and availability mode. Use this table to help you decide if you can move from one instance class type to another, or from one availability mode to another. If your source DB instance has more databases than the target instance class type or availability mode can support, modifying the DB instance fails. You can see the status of your request in the Events pane.

Instance class type	Single-AZ	Multi-AZ with DBM	Multi-AZ with Always On AGs
db..micro to db..medium	30	N/A	N/A
db.*.large	30	30	30
db..xlarge to db..16xlarge	100	50	75
db..24xlarge to db..32xlarge	100	50	100
* Represents the different instance class types.
For example, let's say that your DB instance runs on a db..16xlarge with Single-AZ and that it has 76 databases. You modify the DB instance to upgrade to using Multi-AZ Always On AGs. This upgrade fails, because your DB instance contains more databases than your target configuration can support. If you upgrade your instance class type to db..24xlarge instead, the modification succeeds.
If the upgrade fails, you see events and messages similar to the following:

Unable to modify database instance class. The instance has 76 databases, but after conversion it would only support 75.
Unable to convert the DB instance to Multi-AZ: The instance has 76 databases, but after conversion it would only support 75.
If the point-in-time restore or snapshot restore fails, you see events and messages similar to the following:
Database instance put into incompatible-restore. The instance has 76 databases, but after conversion it would only support 75.

The following ports are reserved for Amazon RDS, and you can't use them when you create a DB instance: 1234, 1434, 3260, 3343, 3389, 47001, and 49152-49156.
Client connections from IP addresses within the range 169.254.0.0/16 are not permitted. This is the Automatic Private IP Addressing Range (APIPA), which is used for local-link addressing.
SQL Server Standard Edition uses only a subset of the available processors if the DB instance has more processors than the software limits (24 cores, 4 sockets, and 128GB RAM). Examples of this are the db.m5.24xlarge and db.r5.24xlarge instance classes.
For more information, see the table of scale limits under Editions and supported features of SQL Server 2019 (15.x) in the Microsoft documentation.
Amazon RDS for SQL Server doesn't support importing data into the msdb database.
You can't rename databases on a DB instance in a SQL Server Multi-AZ deployment.
Make sure that you use these guidelines when setting the following DB parameters on RDS for SQL Server:
- max server memory (mb) >= 256 MB
- max worker threads >= (number of logical CPUs * 7)
  For more information on setting DB parameters, see Parameter groups for Amazon RDS.
The maximum storage size for SQL Server DB instances is the following:
- General Purpose (SSD) storage – 16 TiB for all editions
- Provisioned IOPS storage – 64 TiB for all editions
- Magnetic storage – 1 TiB for all editions
  If you have a scenario that requires a larger amount of storage, you can use sharding across multiple DB instances to get around the limit. This approach requires data-dependent routing logic in applications that connect to the sharded system. You can use an existing sharding framework, or you can write custom code to enable sharding. If you use an existing framework, the framework can't install any components on the same server as the DB instance.
The minimum storage size for SQL Server DB instances is the following:
- General Purpose (SSD) storage – 20 GiB for Enterprise, Standard, Web, and Express Editions
- Provisioned IOPS storage – 20 GiB for Enterprise, Standard, Web, and Express Editions
- Magnetic storage – 20 GiB for Enterprise, Standard, Web, and Express Editions
Amazon RDS doesn't support running these services on the same server as your RDS DB instance:
- Data Quality Services
- Master Data Services
  To use these features, we recommend that you install SQL Server on an Amazon EC2 instance, or use an on-premises SQL Server instance. In these cases, the EC2 or SQL Server instance acts as the Master Data Services server for your SQL Server DB instance on Amazon RDS. You can install SQL Server on an Amazon EC2 instance with Amazon EBS storage, pursuant to Microsoft licensing policies.
Because of limitations in Microsoft SQL Server, restoring to a point in time before successfully running DROP DATABASE might not reflect the state of that database at that point in time. For example, the dropped database is typically restored to its state up to 5 minutes before the DROP DATABASE command was issued. This type of restore means that you can't restore the transactions made during those few minutes on your dropped database. To work around this, you can reissue the DROP DATABASE command after the restore operation is completed. Dropping a database removes the transaction logs for that database.
For SQL Server, you create your databases after you create your DB instance. Database names follow the usual SQL Server naming rules with the following differences:
- Database names can't start with rdsadmin.
- They can't start or end with a space or a tab.
- They can't contain any of the characters that create a new line.
- They can't contain a single quote (').
SQL Server Web Edition only allows you to use the Dev/Test template when creating a new RDS for SQL Server DB instance.

Compliance program support for Microsoft SQL Server DB instances

AWS Services in scope have been fully assessed by a third-party auditor and result in a certification, attestation of compliance, or Authority to Operate (ATO). For more information, see AWS services in scope by compliance program.

HIPAA support for Microsoft SQL Server DB instances

You can use Amazon RDS for Microsoft SQL Server databases to build HIPAA-compliant applications. You can store healthcare-related information, including protected health information (PHI), under a Business Associate Agreement (BAA) with AWS. For more information, see HIPAA compliance.

Amazon RDS for SQL Server supports HIPAA for the following versions and editions:

SQL Server 2022 Enterprise, Standard, and Web Editions
SQL Server 2019 Enterprise, Standard, and Web Editions
SQL Server 2017 Enterprise, Standard, and Web Editions
SQL Server 2016 Enterprise, Standard, and Web Editions

To enable HIPAA support on your DB instance, set up the following three components.

Component	Details
Auditing	To set up auditing, set the parameter rds.sqlserver_audit to the value fedramp_hipaa. If your DB instance is not already using a custom DB parameter group, you must create a custom parameter group and attach it to your DB instance before you can modify the rds.sqlserver_audit parameter. For more information, see Parameter groups for Amazon RDS.
Transport encryption	To set up transport encryption, force all connections to your DB instance to use Secure Sockets Layer (SSL). For more information, see Forcing connections to your DB instance to use SSL.
Encryption at rest	To set up encryption at rest, you have two options: If you're running SQL Server 2016–2022 Enterprise Edition or 2022 Standard Edition, you can use Transparent Data Encryption (TDE) to achieve encryption at rest. For more information, see Support for Transparent Data Encryption in SQL Server. You can set up encryption at rest by using AWS Key Management Service (AWS KMS) encryption keys. For more information, see Encrypting Amazon RDS resources.

Multi-AZ deployments using Microsoft SQL Server Database Mirroring or Always On availability groups

Amazon RDS supports Multi-AZ deployments for DB instances running Microsoft SQL Server by using SQL Server Database Mirroring (DBM) or Always On Availability Groups (AGs). Multi-AZ deployments provide increased availability, data durability, and fault tolerance for DB instances. In the event of planned database maintenance or unplanned service disruption, Amazon RDS automatically fails over to the up-to-date secondary replica so database operations can resume quickly without manual intervention. The primary and secondary instances use the same endpoint, whose physical network address transitions to the passive secondary replica as part of the failover process. You don't have to reconfigure your application when a failover occurs.

Amazon RDS manages failover by actively monitoring your Multi-AZ deployment and initiating a failover when a problem with your primary occurs. Failover doesn't occur unless the standby and primary are fully in sync. Amazon RDS actively maintains your Multi-AZ deployment by automatically repairing unhealthy DB instances and re-establishing synchronous replication. You don't have to manage anything. Amazon RDS handles the primary, the witness, and the standby instance for you. When you set up SQL Server Multi-AZ, RDS configures passive secondary instances for all of the databases on the instance.

For more information, see Multi-AZ deployments for Amazon RDS for Microsoft SQL Server.

Using Transparent Data Encryption to encrypt data at rest

Amazon RDS supports Microsoft SQL Server Transparent Data Encryption (TDE), which transparently encrypts stored data. Amazon RDS uses option groups to enable and configure these features. For more information about the TDE option, see Support for Transparent Data Encryption in SQL Server.