Using Custom RDS Databases

Is is commonly known that RDS supports a number of different database formats and that AWS provides full-stack support for the database engine – including the operating system.

In the majority of cases, this works well. However, there are some edge cases where this approach may not provide the necessary flexibility. Edge cases can include, for example:

1. The need to migrate a database that uses vendor-specific functions that require access to the underlying database (for example – the incredibly dangerous xp_cmdshell on MSSQL, and the BCP command);
2. The need to migrate a database with complex functions (i.e. PL-SQL Procedures, T-SQL Functions) that use commands that are disabled by default under a standard AWS RDS Database.

These are also some of the very same reasons that cloud nay-sayers may use to exclude their application from a cloud migration!

So – what can we do?

Introducing RDS Custom Databases

An RDS custom database uses the same RDS control plane with the following benefits:

1. A DNS entry for your database if it is publicly available;
2. Patching and Upgrades of the Database Engine;
3. Automated AWS Backups.

However, a custom database is installed on an EC2 instance that can be accessed by the engineer – enabling perform additional configuration, or to support additional – previously disabled – commands.

The following diagram is a simple illustration of how this works in practice.

I successfully created a Custom MSSQL database, enabled the xp_cmdshell command, and then ran a dir statement against SQL Server:

exec xp_cmdshell 'dir c:\'

This provided the following output, proving that MSSQL now has access to the underlying operating system:

 Volume in drive C has no label
 Volume Serial Number is XXXX-XXXX


 Directory of c:\


11/14/2018  06:56 AM    <DIR>          EFI
05/13/2020  05:58 PM    <DIR>          PerfLogs
06/27/2022  09:38 PM    <DIR>          Program Files
04/06/2022  10:02 PM    <DIR>          Program Files (x86)
06/27/2022  09:36 PM    <DIR>          RDSCustom
06/27/2022  09:36 PM    <DIR>          Users
06/27/2022  09:32 PM    <DIR>          Windows
06/27/2022  09:38 PM    <DIR>          windrbd.

Lessons Learned

1. Read the pre-requisites for creating a custom database very carefully;
2. Make sure you add the required prefix to the Instance Role Name that you create for your database;
3. Some properties that you can change after you have deployed an RDS database cannot be changed after you have deployed an RDS Custom Database (i.e. attached security groups) – therefore – be careful to get your configuration correct the first time.

To summarise, you can now deploy an RDS database with access to the underlying operating system, additional SQL Extensions, and previously disabled commands.

Notes

• Only MSSQL and Oracle are currently supported;
• Only select regions are available (please see here: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/custom-reqs-limits.html for more information);
• You must create an additional Instance Role for your RDS instance, and it must – unusually – start with the following text: “AWSRDSCustom”; further the role must have access to CloudWatch for logging purposes;
• AWS will check your configuration on a regular basis to ensure it doesn’t fall outside the AWS “Support Perimeter“. This is common sense as your CSP cannot be expected to support everyone’s custom configurations if they stray outside the AWS Support Perimeter.

A (few) words of caution

This approach should not be used unless necessary. For all other use cases, you should select a standard RDS offering, because:

1. When using MSSQL Custom RDS Databases: (a) only a single EC2 instance is supported, and (b) AWS Server licenses are used;
2. When using Oracle Custom RDS Databases: you need to create your own CEV manifest for deploying Oracle
3. The attack surface area is increased – now you are responsible for the operating system as well as the database. Previously, this would have been the responsibility of RDS. There, therefore, is an additional operational and risk overhead with a Custom Database.

For other use cases, and to enable the migration of legacy databases, this approach may make sense – whilst (of course!) you plan to standardise your database and reduce dependency on legacy vendor-specific functions.

Note: This article is an opinion and does not constitute professional advice – any actions taken by a reader based on this article are at the discretion of the reader, who is solely responsible for the outcome of those actions.