Introducing Amazon RDS on VMware
Just like AWS RDS in the public cloud, but running on-premise on VMware with a few considerations.
In This Article
When considering the term "hybrid cloud," the first thing that comes to mind is the idea of extending the on-premises data center into the Public Cloud - AWS or Azure, for example.
But what about the reverse, deploying native cloud services locally? With Amazon's release of RDS on VMware, it is possible.
What is Amazon RDS on VMware?
Amazon RDS (Relational Database Service) on VMware provides a database as a service (DBaaS) offering, allowing for the provisioning of database instances within a local, on-premise VMware vSphere data center with the same familiarity and ease-of-management of the public cloud AWS RDS.
Amazon RDS on VMware lets organizations deploy fully-managed databases into their own data centers with just a few mouse clicks (six mouse clicks to be specific). Patching and maintenance are handled natively by the product, allowing organizations to focus their resources on applications and data management.
Why Do Businesses Need It?
Some businesses aren't able to use public cloud services such as RDS due to data locality, sovereignty and availability challenges. With Amazon RDS on VMWare, these organizations can deploy fully managed databases into their own data centers with most of the same features and abilities as the public cloud service. This allows them to keep potentially sensitive data local, while also enjoying reduced administrative overhead and freeing up their system administrators and developers.
Getting started with RDS on VMware is simple. After creating a custom Availability Zone in AWS (only one page, three options) and setting up the vSphere environment (creating four portgroups and a Resource Pool), an installer appliance is downloaded and deployed locally. This deploys a set of supporting virtual machines that provide VPN connectivity to AWS and store local snapshots and backups. While creation and management of the DB instances is handled from the AWS RDS interface, all data remains in your on-premise data center.
The process for spinning up native is the same as that for an on-premises instance. As shown in Figure 2, it is just a matter of selecting "On-premises" rather than "Amazon Cloud." Then, options are given for selecting the instance size, storage, and any standard configuration options.
After the initial deployment, new instances take less than 10 minutes from clicking "Create database" to connecting and using them. Currently, there is a limited subset of available database engines and versions as compared with native RDS, but this will probably grow over time.
Upgrades and maintenance are also similarly streamlined, with scaling taking about five minutes (select new instance size, click submit, get bigger database server) and snapshot/backup operations taking less than three minutes. Scaling (up or down) is a matter of selecting the new instance size and choosing whether to apply immediately or during the next maintenance window.
Once provisioned, the RDS instances can then be monitored using CloudWatch and managed through any of the tools most are already familiar with, whether it be the Management Console or the CLI/SDK.
There are some limitations that should be explored before diving in, as there are some features available with native RDS that aren't available with on-prem. Multi-AZ and read-replicas are not yet an option, so failover is limited to a single zone and performance is limited to a single instance of the type specified during deployment. Fortunately, as stated earlier, instance size can easily be adjusted later during a maintenance window.
Storage for RDS on VMware presents further limitations. All instances are deployed to the same vSphere data store specified during setup and the only configurable option presently is Allocated Storage. Provisioned IOPS is not available, nor is storage auto-scaling. Attention needs to be paid to sizing deployments adequately or capacity could become a concern.
If none of the technological limitations are showstoppers, the next thing to look at is cost. Current pricing for the smallest general purpose instance, the db.mv11.medium with 1vCPU and 4 GiB of RAM, will run about $62/month. For comparison, an on-demand db.t3.medium instance with 20GiB of general purpose storage runs about $53/month. Running RDS on-premise on one’s own infrastructure can actually cost more than running it within AWS.
Why use such a service? If applications are already running natively in AWS, or RDS is already in use, this probably isn't the right solution. Given the steep price, it’s also not the right fit if cost is a concern. However, if the need is for a locally-deployed database as a service with low or no management overhead, this can be a viable alternative to self-managed database servers. As stated, a new database can be up and running in a matter of minutes and all management tasks are offloaded. This can also be considered a way to test the waters and prepare for an eventual migration to AWS. This is an interesting offering and is one of several that are blurring the lines between the on-premise data center and the Cloud.
Keep an eye out for future posts, labs, and demos, where we'll do a deeper dive into some of the things discussed here. Break our lab before you break yours!